# Synthetic Worker Architecture ## Digital Robotics, Not Workflow Automation Think of a synthetic worker as a digital robot that learns by demonstration. You show it a skill — share your screen, walk through the procedure, narrate the reasoning — and it learns the skill. Not as a recording. Not as a script. As internalized operational knowledge that it can execute autonomously, adapt to new contexts, and teach to other workers. This is more akin to robotics than to any software automation category. The worker has a cognitive loop, a memory, a personality, and the ability to acquire new capabilities through observation. The platform provides the governance and infrastructure to make that safe at enterprise scale. ## The Cognitive Architecture Each synthetic worker operates within a governed cognitive architecture modeled on how biological cognition organizes perception, reasoning, and action. The architecture has three layers, each monitored by governance firewalls in real time. ### Sensory Layer The sensory layer is how the worker perceives its environment. It ingests information from multiple sources: messages from humans and other workers, documents and data from the knowledge graph, screen content during browser automation, results from previous actions, and system state. The sensory layer does not dump everything into context at once — it uses progressive deepening to load only what is relevant to the current task, managing context window economics carefully. ### Cognitive Layer The cognitive layer is where reasoning happens. The worker maintains persistent working memory — an accumulated context that grows across interactions and tasks. This working memory carries the worker's understanding of what it has done, what it is doing, why, and what it should do next. The cognitive layer is responsible for: - Planning multi-step task execution - Deciding which capabilities (MBUs) to invoke - Reasoning about ambiguity and requesting clarification when needed - Integrating corrections and rationale from human reviewers - Maintaining coherent behavior across long-running tasks Working memory is not a chat history. It is a structured, persistent record of the worker's entire cognitive state for a given task or thread. It survives across interactions and is available to the next decision the worker makes. ### Motor Layer The motor layer is how the worker acts on the world. Actions are executed through Motor Building Units (MBUs) — discrete, composable capabilities that the worker can invoke. Each MBU is a self-contained unit of action that reads its own context, makes its own LLM subcalls, and writes its results back for the cognitive layer to process. The motor layer does not execute arbitrary code. Every capability is pre-approved, governed, and auditable. The worker can only do what its MBU activation list permits. ## Motor Building Units (MBUs) MBUs are the synthetic worker's hands. Each MBU: 1. Reads only the context it needs, at the moment it needs it (JIT context injection) 2. Executes one focused capability 3. Returns structured results that feed back into the cognitive layer 4. May trigger further MBU execution (chaining) Active MBUs include: computer use (browser automation via screen capture and keyboard/mouse control), code generation and execution (sandboxed Python with package whitelist), email composition, delegation to other workers, dedicated reasoning steps, web search with iterative refinement, knowledge retrieval with progressive deepening, file operations, calendar integration, and document generation. Reserved MBUs (activated per deployment based on scope): MCP server integration, direct tool connectivity. ## JIT Context Injection Every MBU call decomposes into recursive subcalls, each of which reads only what it needs from the database at the moment it needs it. The system never loads everything upfront. A code generation task doesn't load the entire code library — it searches for relevant existing solutions first, loads only those, and generates new code only if nothing matches. This is critical because context windows are finite and expensive. The architecture is designed around the assumption that you will never have enough context window for everything, so you must be surgically precise about what goes in. ## Open-Ended vs. Structured Execution **Open-Ended Mode:** The worker chains actions indefinitely — search, reason, code, execute, search again, compose email. The cognitive layer decides when to stop. Each action's results feed back into working memory, informing the next decision. This is how the worker handles novel, unscripted problems. **Task/SOP Mode:** Pre-defined skill templates with ordered MBU steps provide guardrails. The sequence of capabilities is predetermined by a human-authored SOP. Within each step, the worker still uses full JIT decomposition and cognitive reasoning — but the overall trajectory is constrained. This is how the worker handles repeatable, compliance-sensitive procedures where the process must be the same every time. Most real-world work involves both modes. A worker might execute a structured SOP for the main workflow and drop into open-ended mode to handle an exception case, then return to the SOP. ## Identity and Personality Each synthetic worker has a configurable identity: name, job role, personality (Big Five traits), motivation, and self-concept. These are not cosmetic labels — they produce measurably different behavioral tendencies. A worker configured with high conscientiousness and low extraversion behaves differently from one configured for high openness and moderate agreeableness. Identity configuration happens during the scoping phase of each engagement, typically informed by lightweight interviews with the customer's domain experts. The goal is to produce a worker whose behavioral tendencies match the work: a compliance analyst should be cautious and thorough; a creative research assistant should be more exploratory and open. ## Multi-Agent Coordination Synthetic workers communicate with each other and with humans through the same messaging infrastructure. A worker can delegate tasks to other workers, receive results back, and incorporate them into its own reasoning. Workers can disagree, request clarification from each other, and collaborate on multi-step problems. This coordination happens through the platform's attention system — a unified message bus that routes communications between all entities (human and synthetic) based on role, scope, and permissions. There is no special inter-agent protocol. Workers talk to each other the same way they talk to humans. ## Why This Architecture Enables Knowledge Reanimation The three-layer cognitive architecture exists to solve a specific problem: capturing and operationalizing human expertise at scale. The sensory layer ingests the expert's demonstrations. The cognitive layer internalizes the reasoning — not just the steps, but the why behind each decision. The motor layer executes that understanding as real work. And persistent working memory means the knowledge compounds across interactions rather than resetting. When an expert teaches a synthetic worker a procedure, the cognitive architecture ensures that the worker doesn't just record a macro. It builds an operational understanding that can adapt to new contexts, handle exceptions the expert didn't explicitly demonstrate, and improve through correction. This is what makes knowledge reanimation possible — and what distinguishes it from documentation, recordings, or scripted automation. See [knowledge_preservation.md](knowledge_preservation.md) for the full knowledge reanimation thesis. --- *For the interactive visual walkthrough of this architecture, visit: https://usemissioncontrol.com/platform/#architecture-cognitive-arch*