Agent Systems Knowledge Brief: Tasks, Memory and context, Context engineering, Tools and MCP, Multi-agent systems, Agent interoperability

The Agent Systems Knowledge Brief connects the documents people create before a run with the controls and evidence needed after an agent reaches production. A model is only one part of that system. Outcomes also depend on how intent becomes specifications and plans, how work becomes tasks and delegation, how context and memory are managed, and how tools, permissions, evals, and operations constrain action.

This week's rotation covers Tasks, Memory and context, Context engineering, Tools and MCP, Multi-agent systems, Agent interoperability. Each topic starts with a decision rule, names the artifacts that should preserve team knowledge, and links back to primary documentation. The rotation is deterministic: it is generated from reviewed AgentAtlas records rather than engagement trends, vendor sponsorship, or unsourced model output.

1. Tasks

Tasks turn a plan into bounded units with inputs, outputs, dependencies, acceptance checks, and ownership. Agent-ready tasks minimize hidden context and produce results that can be verified and integrated without replaying the entire reasoning process.

**Decision rule:** Split work where outputs can be reviewed independently and dependencies are explicit. Do not create tiny tasks that add coordination cost without creating a meaningful verification boundary.

• What concrete artifact or state change completes this task?
• Which context and dependencies must be supplied rather than rediscovered?
• Can the result be verified and integrated independently?

Working lifecycle

1. **Decompose.** Create tasks around independently testable outputs rather than arbitrary file boundaries. 2. **Execute.** Provide required context, allowed scope, and a clear completion contract. 3. **Integrate.** Verify the output, reconcile dependencies, and update the parent plan.

**Artifacts:** `tasks.md`, `issue`, `acceptance checklist`, `dependency map`.

**Primary documentation:** [Agentic SDD workflow](https://github.github.com/spec-kit/reference/agentic-sdd.html) · [A2A protocol specification](https://a2a-protocol.org/latest/specification/). Open the [Tasks field guide](/topics/tasks) for its evidence ledger and related paths.

2. Memory and context

Context is the information available for the current inference; memory is persisted state that may shape later runs. Reliable systems separate conversation history, durable facts, user preferences, project policy, and derived summaries so each can be governed and refreshed appropriately.

**Decision rule:** Persist only information with a defined future use, owner, retention rule, and correction path. Retrieve the smallest high-signal context needed for the current decision.

• What belongs in immediate context, session history, durable memory, or project instructions?
• Who can inspect, correct, expire, or delete remembered information?
• How will retrieval quality and compaction loss be measured?

Working lifecycle

1. **Classify.** Separate transient context, conversation state, durable memory, and authoritative policy. 2. **Persist.** Use stable identities, scoped storage, retention limits, and correction mechanisms. 3. **Evaluate.** Test retrieval precision, stale-memory behavior, privacy, and compaction loss.

**Artifacts:** `session store`, `memory schema`, `retention policy`, `compaction strategy`.

**Primary documentation:** [Sessions](https://openai.github.io/openai-agents-python/sessions/) · [Effective context engineering for AI agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents). Open the [Memory and context field guide](/topics/memory-context) for its evidence ledger and related paths.

3. Context engineering

Context engineering controls which instructions, examples, tools, retrieved facts, messages, and summaries reach the model at each step. The objective is not maximum context; it is the smallest current set that makes the desired behavior likely and reviewable.

**Decision rule:** Add context only when it changes a named decision or reduces a measured failure. Prefer selective retrieval and structured summaries over accumulating every available token.

• Which information must always be present and which should load on demand?
• What is the provenance and freshness of retrieved context?
• How will context growth, conflict, distraction, and loss be detected?

Working lifecycle

1. **Inventory.** List every source of tokens and the decision each source is meant to support. 2. **Curate.** Rank, retrieve, summarize, and expire context based on relevance and authority. 3. **Measure.** Compare task quality, latency, token use, and failure modes under realistic context loads.

**Artifacts:** `context budget`, `retrieval policy`, `compaction rules`, `provenance metadata`.

**Primary documentation:** [Effective context engineering for AI agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) · [How Claude remembers your project](https://code.claude.com/docs/en/memory). Open the [Context engineering field guide](/topics/context-engineering) for its evidence ledger and related paths.

4. Tools and MCP

Tools let models request deterministic functions; MCP standardizes how compatible hosts discover and call external tools, resources, and prompts. Good tool design minimizes ambiguity, constrains inputs, makes side effects visible, and returns results the model can interpret reliably.

**Decision rule:** Use a local function for application-owned capability and MCP when independently maintained systems need a reusable protocol boundary. Require approval for consequential side effects.

• Is the capability read-only, reversible, consequential, or externally stateful?
• What schema and descriptions make correct tool selection likely?
• How are authentication, authorization, timeouts, retries, and output size controlled?

Working lifecycle

1. **Contract.** Define narrow inputs, outputs, errors, side effects, and authorization requirements. 2. **Connect.** Expose the capability through the simplest appropriate application or protocol boundary. 3. **Verify.** Test discovery, selection, malformed input, permission denial, timeout, and duplicate execution.

**Artifacts:** `tool schema`, `MCP server`, `auth policy`, `approval rules`.

**Primary documentation:** [MCP specification](https://modelcontextprotocol.io/specification/) · [Connect Codex to MCP servers](https://learn.chatgpt.com/docs/extend/mcp). Open the [Tools and MCP field guide](/topics/tools-mcp) for its evidence ledger and related paths.

5. Multi-agent systems

Multi-agent systems divide work among specialized or isolated agents and synthesize their outputs. They are valuable when work partitions cleanly or trust boundaries differ, but they add coordination, context transfer, conflict resolution, and observability costs.

**Decision rule:** Delegate only when a bounded subtask can run with a clear input and completion contract. Keep tightly coupled reasoning in one context until measurement proves otherwise.

• Can the work be partitioned without constant shared-state coordination?
• What context, tools, and permissions does each agent receive?
• Who resolves conflicts and verifies the combined result?

Working lifecycle

1. **Partition.** Split work around independent outputs, expertise, or trust boundaries. 2. **Delegate.** Provide scoped context, tools, budget, and an explicit return contract. 3. **Synthesize.** Resolve overlap and contradictions before verifying the whole outcome.

**Artifacts:** `agent roster`, `delegation contract`, `handoff schema`, `synthesis checklist`.

**Primary documentation:** [Codex subagents](https://learn.chatgpt.com/docs/agent-configuration/subagents) · [Create custom subagents](https://code.claude.com/docs/en/sub-agents). Open the [Multi-agent systems field guide](/topics/multi-agent) for its evidence ledger and related paths.

6. Agent interoperability

Interoperability allows hosts, tools, and independently operated agents to discover capabilities and exchange work through explicit contracts. MCP primarily connects models to tools and context; A2A primarily coordinates agents and task artifacts across service boundaries.

**Decision rule:** Choose the protocol that matches the boundary: MCP for tool or context access, A2A for collaboration with an independently operated agent, and ordinary application APIs when neither abstraction is needed.

• Is the remote party a tool service, context provider, or autonomous agent?
• How are capabilities discovered, authenticated, versioned, and revoked?
• What task state, messages, and artifacts must cross the boundary?

Working lifecycle

1. **Classify.** Identify whether the boundary exposes capability, data, or autonomous collaboration. 2. **Contract.** Publish discovery metadata, schemas, versions, and security requirements. 3. **Operate.** Monitor compatibility, task state, authentication failure, and protocol upgrades.

**Artifacts:** `MCP manifest`, `Agent Card`, `task contract`, `security scheme`.

**Primary documentation:** [MCP specification](https://modelcontextprotocol.io/specification/) · [A2A protocol specification](https://a2a-protocol.org/latest/specification/). Open the [Agent interoperability field guide](/topics/interoperability) for its evidence ledger and related paths.

Apply the rotation to one real workflow

Choose a workflow your team already understands. Write its intended outcome, input, constraints, allowed actions, acceptance evidence, and owner. Then use the six topics above as review lenses. Add only the artifacts and controls that close a named gap. A small, maintained plan or runbook is more valuable than a large document nobody uses.

Keep each artifact connected to operational evidence. Specifications should trace to acceptance tests; plans should trace to decisions and rollback; tasks should produce independently verifiable outputs; memory should have provenance and correction; permissions should match authority; and traces should make failures diagnosable without exposing sensitive content.

Editorial and freshness policy

This brief is generated from AgentAtlas's reviewed knowledge-topic dataset. The source catalog must pass structure, internal-link, primary-source, and review-age checks before publishing. Automation may rotate and format reviewed records, but it cannot silently rewrite the underlying guidance. If a source breaks or the 30-day review window expires, scheduled checks open a review issue and fail instead of continuing to publish stale claims. The dataset was last reviewed on 2026-07-26.