{"slug":"architecture/AGENT_FABRIC","title":"Agent Fabric","section":"architecture","sectionLabel":"Architecture","status":"unclassified","type":"document","path":"architecture/AGENT_FABRIC.mdx","bytes":5287,"description":"The orchestration layer for specialized agents — one user-facing Twin, invisible backstage workers, governed handoff.","updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\nAgent Fabric is the orchestration layer for all agents in SpineWorkspace. It follows one master doctrine:\n\n> **One Workspace. One Spine. One shared Agent Home. One Twin. Many invisible capabilities.**\n\n> **Users work with their business. Twin carries continuity. Agents operate backstage. The system surfaces outcomes, evidence, decisions, and required human attention — not agent machinery.**\n\n## Core Principle: Single Face to the User\n\nThe human user has **one user-facing relationship: their Twin**.\n\nTwin is the sole user-facing orchestrator. Specialist agents operate inside the shared Agent Home and may be orchestrated by Twin, workflows, events, or runtime policy. Their outputs surface to users through Twin or the appropriate Workbench projection — not as competing agents.\n\n```text\nONE SPINEWORKSPACE\n        │\n        ▼\nONE SHARED AGENT HOME\n        │\n        ▼\n      TWIN\nsingle continuity-bearing,\nuser-facing orchestrator\n        │\n        ├── specialists (Triage, Schema-AI, Coworker)\n        ├── skills & playbooks\n        ├── workflows & state machines\n        ├── models (dynamic cost/latency routing)\n        ├── tools / MCP connector pool\n        ├── jobs & normalizers\n        ├── schedules & crons\n        └── runtime workers\n\n            invisible (engine room)\n\nUSER\n │\n ▼\nWork → Awareness → Decide → Act → Continue\n```\n\n## Agent Home\n\nAgent Home is the runtime and working state for all agents. It is the shared engine room — not visible to users, not a source of truth, not a replacement for Spine.\n\n**Contains:**\n- Agent session state\n- Working memory and scratchpads\n- Task queues and assignment state\n- Model routing and cost optimization\n- Tool/MCP connector pool\n- Scheduled jobs and crons\n\n**Rules:**\n- Agent Home is ephemeral — no authority\n- Agent Home state does not persist as canonical truth\n- Agent Home is scoped to tenant and workspace\n\n## Specialized Worker Fleet\n\n| Specialized Capability | Role & Responsibility | Surfacing Rule |\n|----------------------|----------------------|----------------|\n| **Triage Agent** | Scans webhooks, emails, tickets, telemetry. Categorizes severity and domain. | Surfaces to Twin/Workbench. Never pings users directly. |\n| **Schema Agent** | Ingests multi-source data, normalizes into canonical Spine schemas. | Reconciles backstage; never prompts user for mapping chores. |\n| **Coworker Agent** | Domain-specific background reasoning (churn analysis, reconciliation). | Submits structured drafts for Twin synthesis. |\n| **Adaptive Auto-Tuner** | Monitors latency, cost, accuracy; dynamically switches model routing. | Autonomous runtime policy. Optimizes invisibly. |\n| **Hermes Executor** | Dispatches authenticated API mutations after human sign-off. | Logs execution proofs to Fortress Ledger. |\n\n## Agent Types\n\nFrom the canonical ontology:\n\n| Type | Purpose | User-Facing | Authority |\n|------|---------|-------------|-----------|\n| **Twin** | User's AI work partner | Yes | Bounded by role |\n| **Coworker** | Context gathering and support | Yes | Read-only context |\n| **Triage** | Classification and routing | No | Operational state only |\n| **Domain Agent** | Domain-specific expertise | No | Scoped context |\n| **Specialist Agent** | Bounded task execution | No | Scoped context |\n| **Workflow Agent** | Multi-step orchestration | No | Governed execution |\n| **System Agent** | Platform operations | No | Infrastructure scope |\n| **External Agent** | Third-party integration | No | Connector scope |\n\n## Agent Boundaries\n\n**Agents:**\n- Receive scoped context\n- Return results/evidence\n- Do not independently own canonical Work or Organizational Memory\n- Operate within the AI Operational Sandbox\n- Execute only after governance approval\n\n**Agents do NOT:**\n- Own canonical Spine truth\n- Bypass governance\n- Mutate organizational memory directly\n- Act without authorization\n- Replace human judgment for consequential decisions\n\n## ACP vs MCP\n\n| Protocol | Purpose | Scope |\n|----------|---------|-------|\n| **MCP** | AI ↔ Tool / Resource / Capability | Tool invocation |\n| **ACP** | Agent ↔ Agent / Agent ↔ Twin | Work/context handoff |\n\nNeither grants authority. Both preserve tenant, identity, work, context, purpose, provenance, correlation.\n\n## Four Golden Rules\n\n1. **Sole User-Facing Presenter:** Twin is the only agent that speaks to the human user.\n2. **Context & Continuity Stewardship:** Twin preserves cross-session continuity, role awareness, working context.\n3. **Decoupled Internal Execution:** Internal workers run asynchronously without blocking Twin or polluting user focus.\n4. **Governed Human Sign-Off:** Sensitive actions encapsulated into Proposal Cards for human approval.\n\n## Related\n\n- [Twin](/architecture/TWIN) — the user-facing orchestrator\n- [Capability Fabric](/architecture/CAPABILITY_FABRIC) — what agents can execute\n- [Governance](/architecture/GOVERNANCE) — the policy boundary agents respect\n- [Reconciliation](/architecture/RECONCILIATION) — how execution results are verified\n"}