After MCP and A2A, the Development Environment Becomes an Agent Runtime

Let's say a small team has given an AI coding tool permission to view GitHub issues, search logs, run tests, and summarize PRs. At first, productivity goes up. This is because it reads the issue, finds related files, runs tests, and even organizes PR descriptions.

But soon new questions arise. You need to decide which logs the AI ​​can read, how much it can auto-correct after a test failure, whether it should stop when creating a migration, and whether it can include internal error information in the PR summary.

At this moment, the development environment is not just an IDE. We get closer to agent runtime, where AI reads context, calls tools, stops at permission boundaries, and leaves execution history and artifacts.

When you think of a development environment, you usually think of an IDE. Tools like VS Code, IntelliJ, WebStorm, and Cursor. This includes terminal, Git, package manager, browser, DB client, and deployment tool.

The center of the existing development environment was people. A human read the code in the IDE, ran commands in the terminal, interpreted the logs, hit the deploy button, and wrote the PR. The coming of AI coding tools shakes up this premise.

MCP is a protocol that allows LLM applications to connect external data and tools in a standardized way. A2A is an open standard designed to enable different AI agent systems to collaborate using a common communication model.

These are the facts that can be confirmed in the official specifications. The interpretation of this article is not to say that MCP and A2A themselves are complete development platforms, but rather to view them as a signal that the development environment is expanding from a bundle of IDE functions to designing an agent execution environment.

Key takeaways

• MCP is a standardized way to connect LLM applications and external data and tools, with Resources, Prompts, and Tools as key components.
• MCP Prompts explains the structure in which the server provides a prompt template, and the client discovers it and uses it as a user-directed command.
• A2A specification is an open standard for communication and interoperability between independent AI agent systems, and uses concepts such as Agent Card, Task, Message, and Artifact.
• OpenAI Agents SDK Tracing, Guardrails, and Human-in-the-loop show that the agent runtime must include observation, acknowledgment, and verification structures.
• In the future, the development environment is likely to move from a structure where people do everything directly in the IDE to a structure where people design and supervise the agent runtime.

Limitations of IDE-centric development environments

Existing IDEs are a good environment for people to write code. Provides autocompletion, search, refactoring, debugging, test execution, and Git integration. However, the basic premise is still “people-centered.”

This premise is shaken when AI coding tools come in. AI does more than just autocomplete. Explore your code base, modify files, run tests, fix errors, and summarize the results.

[Claude Code official document] (https://code.claude.com/docs/en/best-practices) also describes Claude Code as an agentic coding environment, and explains that when the user explains what they want, Claude explores, plans, and implements it.

Now the development environment must ask these questions:

Copy1What files can AI read?2What tools can AI invoke?3What commands can AI execute?4Where do the results created by AI remain as artifacts?5How are AI decisions and tool calls traced?6At what point should a person sign off?

This question is not sufficiently addressed by IDE features alone. So the necessary concept is agent runtime.

What is agent runtime?

agent runtime is the execution environment required for AI to perform tasks. It's not just code that calls the model API.

Copy1agent runtime =2Model3+ Context4+ Tools5+ Permissions6+ Guardrails7+ State8+ Tracing9+ Artifacts10+ Human Approval

Compared to the existing development environment, it is like this.

agent runtime is “an operating environment that enables AI to do development work.” From this perspective, MCP and A2A are important.

AI Client / CLI

Model

Context Manager

Tool Gateway

Permission Layer

Guardrails

State Store

Trace Store

Artifact Store

Human Approval

MCP: A standard that connects tools and context

MCP stands for Model Context Protocol. The official specification describes MCP as an open protocol for integrating LLM applications with external data sources and tools.

To put it simply, MCP from a developer's perspective is like this.

Copy1Instead of attaching external tools to AI tools in different ways each time,2Let's provide context and tools with a common standard.

For example, let's say your AI coding tool needs to use:

Copy1GitHub Issue2Jira Ticket3project documentation4DB schema5Log Search6run test7code search8deployment status

It would be complicated to attach each tool separately. MCP provides a structure to expose these things in a defined manner between the LLM client and server.

MCP Resources, Prompts, Tools

When looking at MCP from a development workflow perspective, there are three key points:

Resources

This layer handles the context that AI can read. It's closer to the concept of exposing the necessary data in a structured way, rather than just throwing in the entire code base.

Copy1resource://project/architecture2resource://project/api-schema3resource://logs/recent-errors4resource://issues/current-sprint5resource://docs/coding-convention

Prompts

[MCP's prompt function] (https://modelcontextprotocol.io/specification/2025-11-25/server/prompts) explains the structure in which the server exposes the prompt template to the client and allows the client to discover it and use it by entering arguments.

The development team can use it this way.

Copy1/review-api-change2/write-regression-test3/analyze-prod-log4/summarize-pr5/refactor-component

Importantly, these commands are not simple prompts but can be tied to your team's work rules.

Tools

The last layer is the functions that the AI ​​can execute.

Copy1search_code()2read_file()3run_tests()4query_logs()5create_pr_summary()6get_issue()

When applied, adding an MCP is about increasing productivity and at the same time designing permissions. Because tools can be external system access or code execution paths, user consent, data privacy, and tool safety must be addressed together.

A2A: Agent-to-Agent Collaboration Protocol

If MCP is closer to connecting AI and tools, A2A is closer to connecting AI to AI.

A2A official specification describes the A2A Protocol as an open standard for communication and interoperability between AI agent systems that are independent and whose internals may be opaque. It also explains that it helps agents securely exchange information to achieve user goals without accessing each other's internal state, memory, or tools.

The core concepts of A2A are:

If you change it to a development workflow, you can see it like this.

1. 01Planner Agent
2. 02Coder Agent
   component artifact
3. 03Test Agent
   test report artifact
4. 04Reviewer Agent
   review artifact
5. 05Release Agent
   release note artifact

The reason A2A is important is because in the future, AI work is unlikely to be completed within a single agent.

Core components of agent runtime

If you view the agent runtime as a development environment, you will need the following components:

OpenAI Agents SDK Tracing explains that it records LLM generation, tool call, handoff, guardrail, custom event, etc. during agent run. The human-in-the-loop document describes a structure in which run stops when a tool call requests approval and resumes after a person approves or rejects the pending approval.

Copy1You can't debug without Trace.2Without approval, dangerous execution cannot be prevented.3Results cannot be verified without artifacts.

How is the development workflow changing?

The existing development workflow was roughly like this.

Copy1Check requirements2to write code3to test4to review5to distribution

When AI agent runtime comes in, the flow changes.

Copy1Requirements Agreement2to Configure Context3to agent work plan4to call tool5to change code6to automatic verification7to submit evidence8to person approval9→ PR merge

The human role does not disappear. You go from being a hands-on implementer to a designer and approver of a work system.

Practical architecture example

Here's a simple agent runtime structure that your team can apply right away:

AI Client / CLI

Context Manager
AI_GUIDE · TASK_CONTRACT · Docs · Logs

MCP Tool Gateway
Code Search · Test Runner · Issue · Log Query

Permission Layer
Allow read/test · Permit write · Block secret/deploy

Guardrails
secret check · dangerous command check · output validation

Trace Store
tool calls · approvals · failures

Artifact Store
code diff · VERIFY_REPORT · PR summary

You don't have to build it as a platform from scratch. Initially, you can start with documents and PR templates.

Copy1AI_GUIDE.md2TASK_CONTRACT.md3VERIFY_REPORT.md4PR_TEMPLATE.md

Then, in the application step, attach the MCP server, add an acceptance gate, and save the trace.

Starting with at least agent runtime

At a minimum, the agent runtime can be launched with three files, three commands, and three authorization rules rather than a separate platform.

To put it into perspective, the following is the first step.

Copy1minimum_agent_runtime:2context:3required_files:4- AI_GUIDE.md5- TASK_CONTRACT.md6tools:7allow:8- npm run lint9- npm run typecheck10- npm test11require_approval:12- npm install13- npm run db:migrate14- npm run deploy15evidence:16required_artifacts:17- VERIFY_REPORT.md18- PR summary

This alone transforms AI tasks from spontaneous execution in a conversation window to reviewable runtime events.

Security and permission risks

agent runtime is powerful. Being powerful also means being dangerous.

Risks to watch out for are as follows:

When designing an agent runtime, a security layer must be included from the beginning.

Copy1Design permissions before connecting tools.2Create approval conditions before opening permissions.3Define prohibited areas before creating approval conditions.

Application roadmap

Step 1: Document-Based Runtime

Initially, a document-based runtime may be sufficient to create a boundary.

Copy1AI_GUIDE.md2TASK_CONTRACT.md3VERIFY_REPORT.md4PR_TEMPLATE.md

The goal is to transform AI work from ad hoc tasks in a chat window to reviewable units of work.

Step 2: Limit tools

The tools are then divided by risk.

Copy1allowance:2- Read files3- Code search4- lint5- typecheck6- unit test7 8Approval required:9- Edit files10- change dependency11- Create migration12 13prohibition:14- secret access15- production distribution16- Change DB directly

Step 3: MCP introduction

Separates recurring tool connections to the MCP server.

Copy1docs server2issue server3log server4test server5code search server

At this time, approval conditions for each tool are also designed.

Step 4: Save Trace

The minimum records that should be stored are:

Copy1context used2tool called3command failed4generated diff5Is it human approved?6Verification results

Step 5: Multi-Agent Collaboration

Dividing roles allows for clearer boundaries between tasks and artifacts between agents.

Copy1Planner Agent2Coder Agent3Test Agent4Reviewer Agent5Release Note Agent

From this stage, concepts like A2A become important. A2A proposes a direction for agents to perform capability discovery, modality negotiation, and collaborative task management without accessing each other's internal tools or memories.

checklist

When designing an agent runtime, check the items below in order:

Copy1[ ] Defined the context range that AI can read.2[ ] Files and data that AI should not read are defined.3[ ] There is a list of tools that AI can call.4[ ] The permission level for each tool is defined.5[ ] Commands that can be executed without approval are divided into commands that require approval.6[ ] Secret, production, and DB changes are blocked by default.7[ ] There is a way to record the status of AI tasks.8[ ] You can track AI tool calls and failure records.9[ ] The results of the work remain as artifacts.10[ ] You can check the evidence in PR.11[ ] During multi-agent collaboration, task and artifact boundaries are defined.

finish

MCP and A2A are not simply new AI technology keywords.

MCP is a trend that seeks to standardize how AI handles external tools and context. A2A is a trend that seeks to standardize the way AI agents discover each other, exchange tasks, create artifacts, and collaborate.

The directions these two currents point in are clear. A development environment is no longer defined solely by the IDE.

What ties it all together is agent runtime.

Copy1Past development environment:2A person writes code in an IDE.3 4Current development environment:5Humans edit code together with AI.6 7The following development environments:8A person designs and supervises the agent runtime.

Developers now need to design not only their code, but also how AI handles the code.

summary card

The essence of this article can be condensed into an execution perspective as follows.

Copy1One line summary:2After MCP and A2A, the development environment moves to focus on agent runtime rather than IDE.3 4Key concepts:5MCP Resources, Prompts, Tools / A2A Agent Card, Task, Message, Artifact6 7Biggest risks:8Connect tools first and think about permissions, approvals, and traces later.9 10What to do right now:11Separate the list of tools that AI can call from the list of tools that require approval.