Agent Architecture Decision Memo: Subagents vs Automations + MCP vs A2A

The Agent Architecture Decision Memo turns frequently confused parts of the agent stack into reviewable implementation choices. It is written for teams deciding where context, capability, delegation, connectivity, persistence, and control should live—not for collecting more framework names.

This week's memo covers Subagents vs Automations and MCP vs A2A. Each decision starts with the smallest layer that solves the problem, makes the trust boundary visible, and defines evidence a reviewer can use before rollout.

Decision 1: Subagents vs Automations

**The question:** Should work be delegated inside a live session or run unattended on a trigger?

Subagents divide bounded work inside an active agent session. Automations run a stable workflow later or repeatedly, with durable scheduling, permissions, and recovery.

**Short answer:** Use a subagent when a coordinator is present to assign and synthesize the task. Use automation when the same task can run safely from predefined inputs without live supervision.

Choose Subagents and agent teams when

• Independent research or tests can return a concise result to a coordinator.
• The main context would otherwise be flooded with logs or source material.
• A specialist needs narrower tools, permissions, or instructions for one run.

Choose Automations when

• The trigger, inputs, output, owner, and completion check are known in advance.
• Retries are idempotent and side effects have explicit approval boundaries.
• Run logs and failures need durable operational ownership.

Combine the layers deliberately

1. Let a scheduled automation create a bounded task and gather required inputs. 2. Use subagents only for independent workstreams within that run. 3. Make the parent automation verify and persist the final result before publishing or acting.

Before implementation, answer these checks:

• Is a human or coordinator available when ambiguity appears?
• Can tasks be partitioned without conflicting writes?
• Can retries duplicate messages, deployments, or charges?
• Are permissions inherited and constrained as expected?
• Can operators reconstruct and recover a failed run?

**Primary documentation:** [Codex subagents](https://learn.chatgpt.com/docs/agent-configuration/subagents) · [Create custom subagents](https://code.claude.com/docs/en/sub-agents) · [Run agents in parallel](https://code.claude.com/docs/en/agents) · [Codex automations](https://learn.chatgpt.com/docs/automations).

The maintained comparison remains available at [AgentAtlas](/compare/subagents-vs-automations).

Decision 2: MCP vs A2A

**The question:** Does an agent need a tool, or does it need to collaborate with another agent?

MCP exposes tools, resources, and prompts to a client. A2A exposes an independently operated agent that accepts messages, manages task state, and returns artifacts.

**Short answer:** Use MCP for capabilities the calling agent should invoke as tools. Use A2A when the remote system owns its own agent loop, task lifecycle, and independently managed trust boundary.

Choose Tools and MCP when

• The capability has typed inputs, outputs, and understandable side effects.
• The caller should decide when and how the capability is used.
• Several compatible clients should discover the same server.

Choose Agent-to-agent protocols when

• The remote party decides how to complete a delegated outcome.
• Tasks can be long-running, asynchronous, or require additional input.
• The remote agent is independently deployed, secured, and operated.

Combine the layers deliberately

1. Use A2A for collaboration across agent boundaries. 2. Let each participating agent use MCP internally for its own tools and data. 3. Keep identity, authorization, and audit evidence explicit at both boundaries.

Before implementation, answer these checks:

• Is the remote capability deterministic enough to be a tool?
• Who owns task planning and lifecycle state?
• Can discovery happen before sensitive data is shared?
• Are retries, cancellation, and duplicate work handled?
• Can each system authenticate and authorize the other?

**Primary documentation:** [MCP specification](https://modelcontextprotocol.io/specification/) · [Connect Codex to MCP servers](https://learn.chatgpt.com/docs/extend/mcp) · [A2A protocol specification](https://a2a-protocol.org/latest/specification/).

The maintained comparison remains available at [AgentAtlas](/compare/mcp-vs-a2a).

A shared decision method

For either choice, begin with one representative workflow. Record its input, expected outcome, required context, available tools, side effects, review owner, and recovery path. Implement the least capable design that can complete that workflow reliably. Add a new layer only when a measured failure identifies what the current design cannot provide.

Treat discovery as a convenience and trust as a separate review. A Markdown filename, manifest, agent card, plugin listing, or server registry helps people and machines find a capability. It does not establish maintenance, compatibility, security, or production readiness. Inspect ownership, source revisions, executable components, permissions, and failure behavior before adoption.

Editorial status

This memo is generated from AgentAtlas's reviewed comparison and Agent Stack datasets. Commercial partners may sponsor distribution, but they cannot buy a ranking, conclusion, or recommendation. The underlying guides must pass review-age, structure, primary-source, link, and application build checks before scheduled publishing continues.