Agent Architecture, MCP, Tools, Context, and Memory
Define the complete, versioned runtime surrounding a model driven engineering worker.
A focused view of boundaries, contracts, state, authority, failure paths, and tradeoffs drawn from this chapter.
Reconstruct and defend this chapter’s architecture.
Reconstruct the architecture, name each boundary, and defend the tradeoffs.
Jump to validation criteriaOpen the source exercise
Draw a host containing an agent runtime, one MCP client per connected server, a context compiler, memory view, model profile, policy gateway, durable state, tool adapters, and an independent evidence path.
Add a malicious repository document that asks the agent to read a synthetic secret and send it to an unapproved remote service. Show:
- where the content enters as untrusted reference context;
- which identity, scope, egress, and approval checks deny the action;
- how the denial and attempted call are recorded;
- how the agent continues or escalates safely; and
- which evidence a reviewer receives.
4. Tradeoffs and alternatives
| Choice | Benefit | Cost or risk | Use when |
|---|---|---|---|
| One general agent | Simple operations and fewer handoffs | Broad context and authority; harder diagnosis | The task is bounded and tools are low risk |
| Specialized agents | Context isolation and focused expertise | Coordination cost and handoff loss | Specialization produces a measured quality or latency gain |
| Direct tool adapters | Tight control and simple debugging | Provider-specific integration | The capability surface is small and stable |
| MCP adapters | Interoperability and reusable capability discovery | Additional server, session, identity, and egress boundaries | Multiple hosts or capability providers need a common protocol |
| Retrieval-only context | Current, targeted information | Retrieval error and missing authority | Sources are indexed, versioned, and evaluable |
| Long-term memory | Continuity and compounding knowledge | Staleness, leakage, poisoning, and hidden coupling | Write admission and correction lifecycle are governed |
| Knowledge graph | Relationship traversal and lineage | Ingestion and consistency complexity | Queries genuinely require graph structure and provenance |
Prefer deterministic code for schema validation, parsing, hashing, routing rules, state transitions, policy enforcement, and admission gates. Use models for ambiguous interpretation, planning, comparison, and generation.
Common anti-patterns include granting every discovered MCP tool, treating tool annotations as trusted policy, passing full conversation history to every server, retrying consequential tools without idempotency, storing every agent message as memory, and using more agents to compensate for an undefined workflow.
5. Current Mission Control Implementation
At commit
b31e27564deb1c03c167e61b5ee094567c2ba7b1,
Mission Control contains agent-platform components at different levels of
maturity. This section describes that pinned implementation; it is not a claim
about later commits.
Agent templates, versions, instances, and identities provide versioned registry records. The older agent model also stores role, allowed task types and tools, budgets, status, and heartbeats. A context router combines deterministic rules, classification, confidence, capacity, and budget to choose clarification, deferral, one Task, or coordinator decomposition.
The Context Registry supports versioned packages, semantic version ranges, repository manifests, lock files, published content hashes, installation records, verifiers, and idempotent activation receipts. Executor-facing activation rejects unpublished or hash-mismatched content and links the locked package set to a WorkflowRun. This is a strong example of compiling context rather than copying arbitrary prompt text.
Mission Control records tool calls and applies risk policy, while the executor adapter freezes repository root, allowed paths, isolation, timeout, and model. Provider packages implement structured model tool-call formats.
Memory is partial. packages/memory implements session, project, and global
in-memory abstractions. Convex records run episodes and execution traces and can
consolidate batches into knowledge-graph nodes. The proposed GraphRAG design
identifies missing provenance, contradiction, permission-aware retrieval,
ingestion checkpoints, evaluation, and correction lifecycle. The live audit
described an empty operational graph, so the proposal must not be presented as
a production memory system.
MCP is adjacent rather than a canonical governed subsystem in the pinned baseline. Product documents and plugin guidance describe MCP integrations, but the commit does not prove a first-class server registry, connection policy, capability lifecycle, and end-to-end factory execution through MCP. That remains future work.
Review this chapter.
Challenge a claim, boundary, missing failure mode, unclear term, or unsupported evidence statement.
- Claim
- Boundary
- Failure
- Evidence