Agent Architecture, MCP, Tools, Context, and Memory

3. Enduring Principle

An agent is a governed runtime composition

An engineering agent is a versioned composition of:

identity + objective + instructions + model profile + tools + context + memory view + policy + budgets + state + evaluation profile

Changing any material component changes the worker configuration and may invalidate evidence from an earlier Attempt. A model name alone is never a sufficient reproducibility record.

Separate reasoning from authority

The model can interpret intent, form hypotheses, choose among allowed options, and propose a tool call. It cannot expand its own scope. Before execution, the runtime validates the acting identity, input schema, policy, repository and path scope, risk, budget, approval state, idempotency strategy, and environment.

The result returns as an observation, never as trusted instructions. The runtime records both approved and denied calls so a reviewer can reconstruct what the agent attempted, what actually ran, and why.

Freeze an execution manifest

Every Attempt should resolve mutable configuration into one immutable manifest before work begins. A minimal manifest contains:

attempt_id: attempt-123
work_order_revision: sha256:...
plan_revision: sha256:...
agent_version: agent-implementation-v4
model_profile: code-reasoning-standard-v2
instruction_bundle: sha256:...
tool_grants:
  - name: repository.read_file
    version: 3.2.0
    schema_hash: sha256:...
    scope: read
context_lock: sha256:...
memory_snapshot: sha256:...
policy_bundle: engineering-medium-risk-v5
budgets:
  wall_clock_seconds: 1800
  attempts: 3
evaluation_profile: repository-change-v7

The manifest is a contract, not a log assembled after execution. Runtime events and evidence must point back to it.

MCP is an interoperability boundary

The Model Context Protocol uses a host–client–server architecture over JSON-RPC. The host coordinates model access, consent, security policy, and context. It creates a client for each server connection. The client negotiates protocol version and capabilities, maintains the stateful session, and routes messages. The server exposes focused capabilities.

The stable specification defines stdio and Streamable HTTP transports. A production contract must pin the protocol version, transport, server identity, and negotiated capabilities; “supports MCP” is too vague to be meaningful.

MCP primitives have different control expectations:

Capability negotiation proves that both sides speak a compatible protocol. It does not prove that a server is trustworthy, that a tool is safe, or that the current WorkOrder authorizes its use.

Govern the MCP connection, not only the tool call

An enterprise MCP gateway should require a connection contract with:

For HTTP authorization, tokens must be audience-bound to the intended MCP server. Token passthrough to unrelated downstream services collapses trust boundaries and must not be treated as a shortcut.

Each MCP server is simultaneously a software supply-chain dependency, an identity boundary, and a possible data-egress path.

Tools are behavioral contracts

A tool is not safe because its arguments satisfy JSON Schema. Its contract must also define behavior under success, failure, retry, cancellation, and partial completion.

Protocol errors and tool-execution errors should remain distinct. A malformed request is different from a valid request whose business operation failed. Structured failures help a model correct an input without hiding operational or policy failure.

Context engineering is controlled compilation

Context compilation selects the smallest sufficient set of trusted directives and relevant observations for a decision. It is not a bulk copy of everything the system can retrieve.

The compiler should process inputs in this order:

1. Load authoritative intent, Plan, policy, identity, budgets, and exact source state.
2. Resolve domain terms to canonical concepts and identifiers.
3. Select applicable instructions, skills, and workflow contracts.
4. Retrieve candidate repository facts, documentation, history, and memory within tenant, repository, sensitivity, and time boundaries.
5. Rank candidates by authority, relevance, freshness, diversity, and risk of omission.
6. Detect duplicates, conflicts, staleness, and unresolved terminology.
7. Allocate the context budget, preserving governing constraints before optional examples or history.
8. Emit an ordered context package with source, revision, hash, selection reason, trust class, and truncation record.

Good context architecture keeps five categories visibly separate:

• instructions: trusted runtime directives;
• authoritative context: approved contracts, policy, identity, and source state;
• reference context: documentation and retrieved knowledge;
• working context: transient hypotheses and scratch state; and
• evidence: observations tied to exact actions and artifacts.

More context is not automatically better. Irrelevant content consumes tokens, increases conflicting cues, and can hide the governing constraint.

Memory is governed, typed, and revisable

Memory should improve future decisions without becoming a shadow system of record.

A safe lifecycle is:

observe → quarantine → classify → evaluate → approve → publish → retrieve → correct, expire, or revoke

Memory writes should retain source, scope, time, confidence, sensitivity, owner, lifecycle state, and the evidence supporting promotion. Retrieval must filter by the current identity and authority, return citations and “why retrieved,” and expose contradictions rather than silently choosing a winner.

Deletion, correction, expiry, tenant isolation, and permission changes are first-class lifecycle events. Operational records remain authoritative; memory may reference them but must not rewrite them.

Use multiple agents only for a measurable reason

Add another agent when independent verification, parallelism, context isolation, or specialized expertise produces a measurable gain. Do not create agents merely to imitate an organization chart.

Every handoff needs an explicit input contract, output schema, authority, budget, termination condition, and owner. Shared durable state belongs in the runtime, not in private message history. Independent validation requires a separate evidence path, different incentives or tools where appropriate, and protection against correlated failure—not a different persona name.

Evaluate the complete agent configuration and workflow. A model benchmark alone cannot show whether context selection, tool policy, memory, recovery, or multi-agent coordination works.

8. Notes and lessons learned

• Context locks make invisible behavioral inputs versioned and attributable.
• Schema validation is necessary but cannot express the complete behavioral or authority contract of a tool.
• Protocol capability and organizational permission are separate decisions.
• Memory quality depends more on write admission and correction than on vector search quality.
• Traceability improves only when records share stable Attempt, manifest, artifact, and policy identifiers.
• A small governed agent is usually safer and easier to improve than a large agent whose tools, memory, and context continually expand.

9. Interview and discussion questions

1. What makes an agent different from a model invocation or provider-managed conversation?
2. Which inputs must an execution manifest freeze, and which runtime events must refer back to it?
3. What does MCP standardize, and which governance decisions remain with the host and factory runtime?
4. How do tools, resources, prompts, sampling, elicitation, and tasks differ?
5. Why are JSON Schema validation and capability negotiation insufficient authorization controls?
6. How do you prevent retrieved text, tool descriptions, and tool results from becoming authority?
7. What makes a retry safe for a consequential tool?
8. How should memory contradictions, correction, expiry, and revocation work?
9. When is multi-agent orchestration justified?
10. Which evidence would prove that one complete agent configuration is safer or more effective than another?