How My AI OS Is Built Around Projects Workflows Agents and Controlled Automation

My AI OS is a control and knowledge system around my work. It connects projects, persistent workspaces, reusable workflows, agent roles and tools. Its memory does not belong to one conversation, and its authority does not come from a model saying that an action seems reasonable.

The structure has two important separations. The shared Core defines contracts and operating rules; each project retains its own facts, sources and decisions. The execution supervisor decides the next authorized step; the workflow-governance workspace maintains process definitions rather than acting as a second supervisor.

This is a map of the system’s documented architecture and retained execution evidence. Registered, implemented, tested and currently operating are different states. I do not describe every registered process as an active background automation.

Core and projects keep different kinds of knowledge

Core holds the agent and workflow registries, source and project identity contracts, routing rules, approval controls and common persistence methods. Project configuration connects that common structure to a particular domain.

A project keeps its own business definitions, source permissions, accepted decisions, working documents and history. An analytical rule suitable for one project does not silently become the business rule for every other project.

A workspace is the context and responsibility assigned to a stream of work. It may be represented by a persistent chat, but it is not identical to a workflow. One workspace can execute different workflows; one workflow can involve several workspaces, agent roles and tools.

The canonical knowledge base is the durable reference. Current pointers distinguish accepted state from older drafts. Provider-specific clients can execute work, but they are not permitted to redefine the project’s truth or inherit unrestricted access to its evidence.

The supervisor and workflow system have different jobs

The execution supervisor resolves priority, ownership, dependencies, conflicts and the next permitted route. Before starting work, it checks whether the result already exists, whether another owner is working on it and whether the necessary authority and capability are present.

The central workflow system maintains definitions, inventory, lifecycle, portability and validation. It describes how a process should operate, what evidence it needs and which responsibilities belong to it. It does not acquire global execution or production-write authority merely by defining the workflow.

The supervisor returns to the execution picture after a verified result. A long task is delegated to the existing specialist or suitable execution surface where available. The coordinator retains the compact result and durable references, not every intermediate tool output.

A read-only control view is another component, not another controller. Its registered candidate contract presents canonical state and qualified derived status. Presentation of a status must not grant permissions, activate a job or overwrite the authoritative record.

Eight agent roles describe responsibility rather than eight running models

The Core agent registry defines these functional roles:

• Orchestrator: task routing, composition and project or executor selection.
• Knowledge Steward: provenance, reconciliation and freshness of canonical knowledge.
• Research and Evidence: source investigation and evidence assessment.
• Data and Analytics: pipelines, diagnostics, metrics and reports.
• Web and SEO: web observations, SEO and link analysis.
• Content and Publishing: content lifecycle, artifacts and approved publishing handoffs.
• Operations and Monitoring: events, execution state, checkpoints and receipts.
• Risk and Approval Guard: permissions, sensitivity and consequential-action controls.

An agent role is not a model name, a connector or a continuously running worker. None of these roles may approve its own consequential action. A workflow selects the responsibilities it needs; a compatible executor performs the bounded work.

The concrete definition distinguishes the orchestrator, one primary agent, supporting roles, an approval guard and optional roles. Those bindings are routing metadata. They neither provide a tool that is absent nor grant access that policy does not allow.

A workflow definition is more than a sequence of prompts

Core workflow types include task routing, knowledge ingestion, claim reconciliation, monitoring, report production, run control and cross-project action. A concrete project workflow adds its version, purpose, trigger, inputs, outputs, dependencies, capabilities, agent bindings and maturity state.

For example, the system’s Universal Sync definition takes a pending delta, an expected base and a routing decision. It returns synchronized state, a receipt or a conflict record. Operations and Monitoring is the primary role, the Knowledge Steward supports reconciliation, and the Risk and Approval Guard handles the authority boundary.

A reporting workflow would need different inputs and roles. Reusing the contract structure does not mean copying another project’s metrics, client records or permissions.

Processes progress through documented lifecycle states: discovered, candidate, documented, validated in shadow or replay, assisted execution, production execution and a reviewed reference pattern. Registration is not activation. A repeatable task becomes a reusable workflow through evidence and acceptance, not because its chat has a permanent name.

Tools are capabilities with limits

A tool route specifies what it can read or change, the scope it serves and the evidence needed to use it. The capability registry records routes for authorized knowledge-base access, scheduled or conditional chat tasks, allowlisted Local AI Bridge execution and source-specific read-only connectors.

Google Drive can carry a pending knowledge event. Dropbox-backed storage can retain canonical knowledge. Windows Task Scheduler can trigger an approved local synchronization process. The Local AI Bridge executes registered allowlisted actions rather than arbitrary shell instructions embedded in a conversation.

These are not interchangeable permissions. Reading a source does not allow editing it. Ability to create a file does not allow replacing a protected record. A registered connector is not a universal connection to every account or project.

Before execution, the preflight checks the current owner, canonical state, existing native tools, automation, transport, action registry and source authority. It reuses an existing capability or composes known capabilities before creating another collector, workflow or execution surface.

Knowledge moves as a governed event and returns with a receipt

The event-ingestion contract follows a concrete path: event → normalization → checkpoint → duplicate detection → routing → workflow → run record.

An event carries identity, source, observation time, classification, permitted project scope, provenance and an idempotency key. A checkpoint records what was already processed. Deduplication prevents replay from creating a second result for the same accepted event.

The write path adds the expected source revision, isolated candidate, validation and an authorized publisher. If the expected base no longer matches, the result is a conflict—not a silent overwrite. A successful write needs read-back verification before the receipt can report persistence.

A cross-project transfer follows a separate typed contract: source, destination, purpose, allowed fields, classification, approval and version. The receiving specialist returns a bounded result. The originating project reconciles it; the transfer does not open the entire source knowledge base.

One recorded automation trace shows the mechanism

The architecture record retains a successful scheduled knowledge-persistence acceptance on 18 August 2026. The sequence was a canonical JSON knowledge event from the cloud conversation, Google Drive pending storage, an approved Windows scheduled task, Universal Sync, deterministic routing, local SSOT persistence, validation and read-back, backup, and processed finalization.

That is a system-level transport example, not a website-build story and not a client-data demonstration. The retained acceptance states that the scheduled test did not need a manual shell invocation.

It is also dated evidence, not a claim of continuous availability today. Later status records do not uniformly agree about the cloud persistence boundary. The current availability of that complete route therefore needs reconciled operational evidence before it is relied on for a new execution.

The same controls remain useful even when a route is unavailable: keep the pending event, distinguish it from synchronized state and return the unresolved gate. Do not lose the knowledge or report a queued result as persisted.

Working tools for advertising sales and user behavior

On a marketing task, AI OS uses named sources rather than an abstract data stream. The system registers read routes for Metorik, Meta Ads, Mouseflow and Google analytics. Their retained capability checks are dated September 2026, not certification of access to any account today. Each new request still needs project, permission, period and freshness checks.

Google Ads supplies spend, impressions, clicks and platform-defined conversions. Google Ads API supports reporting, and a retained working configuration describes a separate read route. It does not authorize budget changes. Google Ads API reporting.

Meta Ads is a separate source of spend and platform-reported Facebook and Instagram campaign outcomes. The system registers an account-bounded read route. Marketing API and a connector are access mechanisms, not independent business truth. A Meta-reported conversion does not automatically become a confirmed store sale.

Metorik provides order, revenue, product and refund reporting from the connected store. The available connector exposes get_store_report for report slices. I do not invent an unverified direct public API for it: the actual route described here is the Metorik connector. Using sales still requires agreed order statuses, currency, tax, shipping and refund treatment. Metorik reports.

Mouseflow helps investigate friction through funnels, forms, heatmaps and behavioral signals. Its MCP Server exposes tools over the REST API; available tools include get_funnel, get_top_friction_items and get_page_heatmap. This example needs aggregates, not identifiable session replays. Behavioral evidence informs hypotheses; it does not prove the cause of every lost sale. Mouseflow MCP Server.

GA4 adds acquisition and event reporting. Google Analytics Data API returns report slices; BigQuery can provide a separate route to exported data where that connection is verified for the project. Data API reports and raw BigQuery events are not identical. Google Analytics Data API.

Google Search Console provides organic-search query, page, click and impression evidence. Search Console API retrieves these slices but does not promise every query row. Google Tag Manager manages measurement rather than replacing the sales database. CRM, call tracking and additional sources enter only where they are actually used and authorized in the project. Search Console API.

Northstar shows how the tools lead to a decision

Northstar is a fictional online store. The task is to assess whether more resources should go to Google Ads, Meta Ads or improvements to the purchase page. The scenario combines real role, tool and workflow-type names. It contains no client data, fabricated outcome or newly executed run.

AI OS Execution Supervisor receives the task. AG-001 ORCHESTRATOR resolves the route, owners and dependencies; AI_OS.EXECUTION_SUPERVISION describes that responsibility. The separate AI OS Workflow System workspace maintains definitions and versions, not control of store budgets. The analytics and advertising workspaces in the diagram are functional contexts for illustrative Northstar, not a claim that new persistent chats have been created.

AG-007 OPERATIONS_AND_MONITORING checks collection state, periods and freshness. AG-004 DATA_AND_ANALYTICS uses permitted Google Ads, Meta Ads, Metorik, GA4 and Mouseflow routes. Core names WF-010 DATA_PIPELINE and WF-011 ANALYTICS_DIAGNOSTIC describe relevant process types, not a ready-to-run autonomous Northstar deployment. AG-002 KNOWLEDGE_STEWARD maintains provenance, definitions and reconciled context.

Advertising spend and sales remain separate before reconciliation. Slices align by date, timezone, currency and grain. Relationships use available campaign IDs, UTMs and attribution evidence; not every order can be reliably linked to a particular ad or behavioral session. Unknown stays unknown, and refunds or duplicates must not inflate the result.

Mouseflow may identify a problematic form or funnel step. GA4 can help check events, while Metorik shows whether orders and refunds align. AG-003 RESEARCH_AND_EVIDENCE examines alternative explanations and context; AG-005 WEB_AND_SEO contributes when organic search or the page is relevant. Friction is a hypothesis to investigate, not automatic proof of a revenue loss.

The comparison includes compatible MoM and YoY periods where available, with an explicit reason where a required window is missing. Advertising ROAS remains separate from revenue divided by advertising and marketing-work costs. Platform outcomes are not added together to double-count a sale. Ten dollars of revenue per dollar of costs is a target, not a claimed result or a measure of profit.

WF-012 REPORT_PIPELINE describes producing the result: AG-004 prepares analysis; AG-006 CONTENT_AND_PUBLISHING makes a readable report or dashboard. The recommendation explains the proposed change, supporting evidence and next validation. AG-008 RISK_AND_APPROVAL_GUARD checks authority, while a human decides on budget. Read access through an API cannot silently become campaign-write permission.

After approval, the system retains the conclusion, sources, version and decision, not unrestricted account access. AI_OS.UNIVERSAL_SYNC describes governed reconciliation: AG-007 owns state and receipts, AG-002 knowledge, and AG-008 authority. The next review assesses the new result and compatible periods. This preserves a history of decisions rather than merely generating another report.

Automation remains bounded by controls

The run contract records eligibility, versions, dependencies, resource ownership, validation, receipts and recovery references. Parallel readers and isolated candidate preparation are different from simultaneous direct canonical writes.

A scheduled trigger does not supply approval. A model’s confidence does not supply approval. Sensitive external actions, publication, destructive changes and permission changes remain human-controlled under their applicable policy.

When capability, freshness, classification or authority is unresolved, the affected step stops. The system preserves the prior accepted state and records a failed, pending or conflict outcome. Restarting work requires the right checkpoint and base version rather than repeating completed steps blindly.

Skills and workflows can improve through reviewed project experience. A correction may become a reusable instruction or reference pattern after validation of its scope. That is maintained knowledge and method improvement, not automatic retraining of the underlying model on private client work.

The system is therefore not “one chatbot that knows everything.” It is a structure that connects the right knowledge, responsibility and tool to a defined task—and leaves evidence of what actually happened.