What's Next — The Agent Frontier

Agent-to-agent protocols, Claude's evolving capabilities, responsible AI principles, framework choices, and your 90-day roadmap to continued growth.

Concept Index

Tap to jump to any concept.

• 1
  Emerging Patterns: Agent-to-Agent Protocols
• 2
  A2A In Practice — Publish & Consume
• 3
  Beyond A2A — AGNTCY, ANP & the Landscape
• 4
  Claude's Evolving Capabilities
• 5
  Building Responsibly: Ethics & Human Oversight
• 6
  Agent Frameworks — Do You Need One?
• 7
  Your Personal Agent Development Roadmap

Agent-to-Agent Protocols

Most agents today are isolated islands — they do their one thing but can't discover or collaborate with other agents. The emerging A2A (Agent2Agent) specification is the "API moment" for agent interoperability: a universal wire format that lets any agent discover, negotiate with, and delegate to any other, regardless of which framework or vendor built it.

The key distinction: MCP (Model Context Protocol) governs how one agent connects to its tools — databases, APIs, filesystems. A2A governs how one agent talks to another agent across process or organizational boundaries. Two protocols, two scopes — not competitors.

Analogy

How It Works

1. 1
   Agent publishes an Agent Card

   A JSON document at /.well-known/agent.json listing the agent's name, capabilities, skills, and auth requirements.
2. 2
   Orchestrator discovers the card

   Fetch the card, verify the needed skill exists, verify auth scheme is acceptable.
3. 3
   Orchestrator posts a Task

   POST to /tasks/send with auth token and task payload. Task enters submitted → working → completed lifecycle.
4. 4
   Poll or stream for result

   GET /tasks/{id} to poll, or use SSE stream if the card advertises streaming: true.

Decision Framework

MCP, A2A, or neither?

FUNCTION choose_protocol(scenario):
  # Connect agent to a tool/database
  IF scenario == "agent needs a tool (DB, API, FS)":
    RETURN "MCP"

  # One agent delegates to another agent
  IF scenario == "cross-org or cross-process agent call":
    RETURN "A2A"

  # In-process subagent (M14 style)
  IF scenario == "subagent inside same process":
    RETURN "function call — no protocol needed"

  # Enterprise specialist marketplace
  IF scenario == "team publishes specialist agents":
    RETURN "A2A — Agent Cards are the registry"

Common Misconceptions

A2A In Practice — Publish & Consume

The A2A protocol has two halves. Publishing means exposing three HTTP endpoints: a static Agent Card at /.well-known/agent.json, a POST /tasks/send endpoint, and a GET /tasks/{id} endpoint. That's the entire surface area — your existing Claude agent loop lives inside /tasks/send unchanged.

Consuming means: fetch the card, verify the skill exists, verify auth, post the task, then poll (or stream) until the task reaches a terminal state. The consuming code is the same for any A2A-compliant agent, regardless of whether it was built with the Claude SDK, LangGraph, or a Go service.

Analogy

How It Works

1. 1
   Publish: expose Agent Card

   Static JSON at /.well-known/agent.json: name, description, capabilities (streaming, pushNotifications), auth schemes, and skill definitions.
2. 2
   Publish: wrap your agent loop

   POST /tasks/send runs your existing Claude agent and stores results. The only domain-specific code — everything else is A2A boilerplate.
3. 3
   Consume: discover and verify

   Fetch the card, confirm the skill ID exists, confirm auth scheme is acceptable before sending any task.
4. 4
   Consume: send, poll, extract

   POST task with auth header, poll /tasks/{id} (or use SSE), handle failed/canceled states explicitly.

Pseudocode

# Consumer side: discover → verify → send → poll
FUNCTION call_agent(base_url, question, timeout=30):
  # Step 1: Discover
  card = GET(base_url + "/.well-known/agent.json")

  # Step 2: Verify skill + auth
  skill = find_skill(card, id="deduction-analysis")
  IF skill is NULL: RAISE "Skill not available"
  IF "bearer" not IN card.auth.schemes:
    RAISE "Unacceptable auth scheme"

  # Step 3: Send task
  task = POST(base_url + "/tasks/send", {
    "skillId": skill.id,
    "message": { "role": "user", "text": question }
  }, auth=BEARER_TOKEN)

  # Step 4: Poll until terminal
  deadline = now() + timeout
  WHILE task.state IN ["submitted", "working"]:
    IF now() > deadline:
      POST("/tasks/" + task.id + "/cancel")
      RAISE TimeoutError
    SLEEP(0.5)
    task = GET("/tasks/" + task.id)

  IF task.state != "completed":
    RAISE task.error
  RETURN task.artifacts[0].text

Common Misconceptions

Beyond A2A — AGNTCY, ANP & the Wider Landscape

A2A is the most widely adopted agent-to-agent spec, but two others appear in vendor docs and research: AGNTCY (Cisco-led "Internet of Agents" — a full stack above A2A) and ANP (Agent Network Protocol — a decentralized, DID-based research spec). Knowing which is which prevents confusion when you read framework announcements.

The good news: all three converge on the same shape — agents have cards, tasks have lifecycles, auth is mandatory. Code targeting A2A is largely portable to the others.

Analogy

How It Works

1. A
   A2A (Google → Linux Foundation, 2025)

   Widest production adoption. Agent Cards + task lifecycle + SSE. Your default target. Anthropic, Salesforce, SAP, Atlassian all ship this.
2. B
   AGNTCY (Cisco / Internet of Agents)

   Full stack: adds W3C DID identity for agents, global agent directory, observability layer. A2A-compatible wire. Broader than A2A but still compatible.
3. C
   ANP (Agent Network Protocol)

   Research-oriented. Decentralized peer-to-peer discovery, DID identity, no central registry required. Less production adoption — watch but don't build on yet.

Decision Framework

Which spec to target?

FUNCTION pick_spec(requirements):
  IF requirements.needs_central_registry == FALSE:
    RETURN "ANP"  # decentralized
  IF requirements.needs_did_identity:
    RETURN "AGNTCY"  # full stack
  RETURN "A2A"  # safe default for most teams

Common Misconceptions

Claude's Evolving Capabilities

Each new Claude capability doesn't just add a feature — it unlocks entire categories of applications that were previously impossible. Four capabilities are reshaping what agents can do: Computer Use (GUI automation without APIs), Extended Thinking (dedicated reasoning compute), Skills (just-in-time instruction loading), and larger context windows (less need for RAG on smaller corpora).

Your foundation — tool use, RAG, multi-agent orchestration — multiplies in value as each new capability lands. Developers who understood the raw loop before Computer Use shipped adopted it in hours. Starting from scratch takes weeks.

Analogy

How It Works

1. 1
   Computer Use — GUI without APIs

   Claude receives screenshots and issues click/type/scroll actions. Works with ANY software that has a visual interface — including 15-year-old legacy systems with no API. Always run in a sandboxed Docker container with virtual display (Xvfb).
2. 2
   Extended Thinking — dedicated reasoning

   One thinking: {type: "enabled", budget_tokens: 10000} parameter. NOT chain-of-thought prompting — model-native reasoning compute. Dramatically improves math, architecture planning, multi-constraint problems.
3. 3
   Skills — just-in-time playbooks

   A SKILL.md in .claude/skills/. Only the description frontmatter loads into base context. The procedure body loads only when the agent decides it's relevant — zero cost in steady state.
4. 4
   Larger context — simpler RAG decisions

   When context is large enough, paste the whole document instead of chunking. Still use RAG for very large corpora (cost + latency still matter), but the threshold shifts.

Decision Framework

Tool vs MCP vs Skill vs Subagent vs A2A?

FUNCTION pick_capability(need):
  # Single function call, structured I/O
  IF need == "one function (verb)":
    RETURN "Tool (M05)"

  # Connect to a system (DB, GitHub, Jira)
  IF need == "connect to a system":
    RETURN "MCP server (M07)"

  # Procedure with branches, used occasionally
  IF need == "domain procedure, rarely triggered":
    RETURN "Skill (.claude/skills/)"

  # Parallel specialist, own context window
  IF need == "parallel specialist":
    RETURN "Subagent (M14)"

  # Cross-org / cross-process
  IF need == "capability from another team/org":
    RETURN "A2A agent"

  # No API — legacy system GUI
  IF need == "no API exists":
    RETURN "Computer Use (sandbox required)"

Common Misconceptions

Building Responsibly: Ethics & Human Oversight

Capable agents without safety are not fast — they're dangerous. Five principles separate trustworthy agents from impressive-but-fragile demos: Human-in-the-Loop by design, Transparency, Bias Awareness, Scope Limitation, and Fail-Safe Defaults.

The mark of a senior agent developer is knowing when NOT to automate. Responsible design is not a constraint on capability — it is what makes deployment possible. Teams that build guardrails from the start deploy faster because they spend less time firefighting production failures.

Analogy

How It Works — 5 Principles

1. 1
   Human-in-the-Loop by design

   Critical decisions (medical, financial, legal) require human approval gates — not just kill switches. An approval gate assumes the human is needed. A kill switch assumes the human is watching.
2. 2
   Transparency

   Users should know they're interacting with AI and what it can and cannot do. Transparent agents build trust; trusted agents get adopted.
3. 3
   Bias awareness

   A biased human loan officer affects dozens of decisions per day. A biased agent affects thousands. Audit continuously with diverse test cases — not just at launch.
4. 4
   Scope limitation

   Agents should refuse out-of-domain requests rather than confidently hallucinating. "I can't help with that, but here's who can" is infinitely more useful than confident wrong advice.
5. 5
   Fail-safe defaults (fail open)

   When uncertain, share what you know and defer the decision to a human. "Fail open" beats "fail closed" — a dead end with no information is the worst UX and the least safe outcome.

Decision Framework

Responsible agent decision triage

FUNCTION responsible_decision(request, context):
  # Safety critical → always human
  IF context.is_safety_critical:
    RETURN escalate_to_human(request, reason="safety")

  # Out of scope → refuse gracefully
  IF request.domain NOT IN agent.allowed_domains:
    RETURN refuse("Outside my scope. Try: " + suggest_resource())

  # High-stakes → require approval
  IF context.stakes == "HIGH":
    plan = build_plan(request)
    RETURN request_approval(plan)

  # Uncertain → fail open
  IF confidence < 0.7:
    RETURN {
      "partial": what_i_know,
      "escalate": TRUE,
      "reason": "low confidence"
    }

  # Normal path — proceed
  RETURN execute(request)

Common Misconceptions

Agent Frameworks — Do You Need One?

This course taught raw API first — client.messages.create() inside a while loop. Then the Claude Agent SDK. Then spec-driven generation. That order matters: the developer who understands the raw loop can learn any framework in a day. The developer who learned a framework first often can't debug without it.

By 2026, each major model vendor ships their own first-party agent SDK. If you've committed to a primary model, the vendor SDK usually beats a cross-provider framework on developer ergonomics, latency, and feature coverage.

Analogy

Framework Landscape

Decision Framework

FUNCTION pick_framework(team, use_case):
  # Standardized on Claude? Use native SDK
  IF team.primary_model == "claude":
    RETURN "Anthropic Agent SDK"

  # Need to swap models routinely?
  IF team.needs_model_agnostic:
    RETURN "LangChain / LangGraph"

  # Team-of-specialists pattern?
  IF use_case == "role-based multi-agent":
    RETURN "CrewAI for prototyping"

  # Repository coding work?
  IF use_case == "codebase tasks":
    RETURN "Claude Code (buy not build)"

  # Learning / debugging / custom domain?
  RETURN "Raw SDK — maximum control"

Common Misconceptions

Your Personal Agent Development Roadmap

Developers who finish a course with enthusiasm but no plan build nothing in the following month. "I'll start this weekend" becomes "I'll start next month" becomes "I should retake the course." A structured 90-day plan breaks this cycle.

Five milestones, each building on the previous. The milestones are checkpoints, not deadlines. The goal is a compass bearing: build more capable, more reliable agents. Developers who set a concrete 90-day goal are 3× more likely to ship a project than those with vague intentions.

Analogy

The 5 Milestones

• 1
  Weeks 1–2

  Complete Your Capstone

  Finish your M23 capstone, run the evaluation harness, score yourself. An unfinished capstone = "I learned about agents," not "I can build agents."
• 2
  Month 1

  First Production Deploy

  Deploy your capstone to production — even at small scale. Experience real latency, cost, monitoring, and user behavior that test scenarios miss.
• 3
  Months 2–3

  Novel Agent Project

  Build an agent for a problem you personally care about. You define the requirements. Real learning happens here — nobody hands you a brief.
• 4
  Months 3–6

  Community Contribution

  Open-source a tool, write a post, or help others in communities. Teaching solidifies understanding more than any other activity.
• 5
  Ongoing

  Deep Specialization

  Pick one thread and follow it deeply: multi-agent systems, evaluation, safety/alignment, or domain-specific agents. Breadth got you here; depth keeps you growing.

Pseudocode

# 90-day agent developer roadmap
FUNCTION run_roadmap():
  # Weeks 1-2: finish capstone
  capstone = complete_and_evaluate(m23_project)
  IF capstone.score < passing_threshold:
    iterate(capstone)

  # Month 1: first real deploy
  deploy = ship_to_production(capstone)
  observe(deploy, metrics=["latency", "cost", "errors"])

  # Months 2-3: novel project
  problem = pick_problem_you_care_about()
  novel_agent = build(problem)  # no brief given

  # Months 3-6: give back
  contribute_one_of([
    "open_source_tool",
    "blog_post_about_hard_problem",
    "help_someone_in_community"
  ])

  # Ongoing: go deep on one thread
  thread = pick_one(["multi-agent", "eval",
                        "safety", "domain-specific"])
  LOOP every_90_days:
    review_progress(thread)
    set_next_goal(thread)

Common Misconceptions

Quick Quiz

Tap each answer to reveal.