Every team that gets serious about AI agents hits the same wall, usually around month three. The agent works. It reviews code the way you want, or it triages tickets, or it maintains your data pipelines. Then someone asks a simple question: can we run this somewhere else? Can we move it to the tool the platform team standardized on? Can we share it with the team in another office that uses a different product?
The answer, in most shops, is no. The agent is not a thing you own. It is a configuration scattered across one vendor's product: a system prompt in one screen, tool grants in another, accumulated context in a proprietary store, approval rules in a settings page nobody remembers configuring. The model behind the agent is swappable. The harness around it is not, and the harness is where everything you built actually lives.
This article is about the standards effort to fix that. I am going to walk through six specifications that, together, make the pieces of an agentic system portable: the Model Context Protocol (MCP), Agent Skills, Agent2Agent (A2A), the Open Agent Profile (OAP), the Agentic Graph Specification (AGS), and the Agent Approval Interchange Specification (AAIS). Full disclosure up front: I authored the last three of those, and I work at Dremio, which ships an MCP Server as part of its platform. I will keep the analysis honest anyway, including where each standard is young, unproven, or the wrong tool.
For most of the last decade, the lock-in conversation in data and AI centered on two layers. First it was storage and table formats, which is the fight Apache Iceberg largely settled by making tables an open specification any engine can read. Then it was models, which the market settled through sheer competition. Today you can route a request to a frontier model from any of a half dozen providers, or run an open-weight model on your own hardware, and switch between them in an afternoon.
The harness is the layer that quietly inherited the lock-in. A harness is the runtime around a model: the software that holds the conversation loop, executes tool calls, enforces permissions, manages context, and turns a model's text output into actual work. Claude Code is a harness. OpenAI's Codex CLI is a harness. Cursor's agent mode, Goose, OpenCode, and the internal orchestrators enterprises build on frameworks are all harnesses. The model does the thinking. The harness does everything else.
Everything else turns out to be everything that matters for ownership. Consider what accumulates inside a harness after six months of real use. Agent definitions, meaning the roles, instructions, and personas your team refined through hundreds of corrections. Tool connections, each one configured, authenticated, and scoped. Procedural knowledge, the documented workflows the agent follows for releases, migrations, and reviews. Work plans, the decompositions of big jobs into steps. Approval rules, the record of what requires a human and what does not. And learned state, the facts an agent picked up about your systems that make it useful on day 180 in a way it was not on day one.
None of that has anything to do with which model you use. All of it, absent standards, lives in one product's shape. Switching harnesses means reconstructing it from memory, which is expensive enough that most teams never do it. That is lock-in in its purest form: not a contract, just a moat made of your own accumulated work.
The pattern rhymes with what happened in data infrastructure, and I say that as someone who has spent years teaching that history. Before open table formats, your tables were trapped inside whichever warehouse wrote them. The fix was not a better warehouse. The fix was specifications: Parquet for files, Iceberg for tables, Polaris for catalogs. Each one turned a proprietary internal structure into a document any conforming system reads. The agentic stack is now going through the same transition, one artifact type at a time.
The useful way to hold these six specifications in your head is not as competitors. Each answers a different question about an agentic system, and a complete system needs an answer to all six.
Three of these have institutional weight behind them. MCP and A2A both live at the Linux Foundation now, and Agent Skills is stewarded through the Agentic AI Foundation with adoption across directly competing vendors. The other three are young, and I wrote them, so weigh my enthusiasm accordingly. What I will argue is that the questions they answer are real regardless of whether these particular documents win. If OAP, AGS, and AAIS all get replaced by better specifications next year, the gaps they name will still need filling: agent identity, work shape, and approval interchange have no portable home in the three established standards.
One more framing point before the details. A pile of open components does not automatically produce an open system. The test that matters is whether each artifact type can move: can you take your tool connections, your skills, your agent definitions, your plans, and your approval flows to a different runtime without rewriting them? Every section below is really an answer to that question for one artifact type.
The Model Context Protocol is the oldest of the six and the closest thing the agentic stack has to settled infrastructure. Anthropic released it in November 2024 as an open protocol for connecting AI applications to tools and data. In December 2025 it was contributed to the Agentic AI Foundation under the Linux Foundation, which put it under neutral governance alongside other agent-era building blocks.
The mechanism is straightforward. An MCP server exposes three kinds of things: tools an agent can invoke, resources it can read, and prompts it can use as templates. A client, meaning the harness, connects to servers over stdio for local processes or HTTP for remote ones, speaks JSON-RPC, discovers what each server offers, and makes those capabilities available to the model. The protocol standardizes discovery, invocation, and results. It deliberately does not standardize what the tools do.
The reason MCP matters for harness portability is the shape of the integration problem it dissolves. Before a tool protocol, every harness needed its own connector for every system: N harnesses times M systems means N times M integrations, each one written by whichever vendor got around to it. With MCP, a system exposes one server and every conforming harness can use it. The database vendor writes one server. The ticketing system writes one server. Your internal platform team writes one server for your proprietary services. When you switch harnesses, the connections come with you, because the connections were never the harness's property.
This is where my employer shows up as a worked example, so let me flag it and move on. Dremio ships an MCP Server that lets agents query governed data through the platform's semantic layer, which means an agent in any MCP-capable harness can run SQL against approved datasets with the same access controls a human analyst gets. I am not going to argue that is the right architecture for you. The point that generalizes is that the data platform exposes capability once, through a protocol it does not control, and every harness benefits equally. That is what an open standard buys both sides of the connection.
MCP's limits are worth naming because people ask it to do jobs it was never designed for. It says nothing about which tools an agent should be allowed to use, only how to call them. Authorization lives in the harness. It says nothing about what an agent is, how work decomposes, or how a human approves a dangerous action. It is a reach protocol. Treating it as the whole standards story, which a lot of 2025-era architecture diagrams did, leaves the other five questions unanswered.
The operational caution with MCP is the security surface. Every server you connect is code that feeds content into your agent's context, and content is exactly the channel prompt injection travels through. A malicious or compromised server can return tool results crafted to steer the model. The mitigations are the boring ones: treat servers like dependencies, pin and review them, run them with the least access they need, and keep dangerous capabilities behind approval gates. That last mitigation is a preview of why AAIS exists, and we will get there.
Agent Skills is the standard with the most surprising adoption story, and the structure of the spec explains why. A skill is a folder. Inside the folder is a file named SKILL.md with YAML frontmatter carrying two required fields, a name and a description, followed by a Markdown body of instructions. The folder can also carry scripts, reference documents, and templates the instructions point to. That is the whole format.
The runtime behavior is progressive disclosure. The harness loads only each skill's name and description at startup, which costs a few dozen tokens per skill. When a task matches a description, the harness loads the full body, and the agent reads any bundled files only as needed. The design lets an agent carry a large library of procedures without paying the context cost of all of them on every request.
Anthropic shipped skills as a Claude feature in October 2025 and published the format as an open specification at agentskills.io on December 18, 2025. What happened next is the part worth studying. Microsoft added support in VS Code within days. OpenAI adopted it in ChatGPT and the Codex CLI. By mid 2026 the official showcase lists roughly 40 products reading the same format, including Gemini CLI, GitHub Copilot, Cursor, JetBrains Junie, Goose, OpenCode, and offerings from Databricks and Snowflake. Directly competing vendors adopted a competitor's format in weeks, which almost never happens, and it happened because the spec is small enough to implement in an afternoon and the value of a shared skills library is obvious to everyone's customers.
For the portability argument, skills solve the procedural knowledge problem. The release checklist, the incident triage protocol, the way your team writes migration scripts: before skills, that knowledge lived in tool-specific configuration files, a .cursorrules here, a CLAUDE.md there, none of it portable. A skill written to the spec moves between every conforming product unchanged. I use this daily in my own content work. The skills that produce my newsletters and articles are folders in version control, and nothing about them belongs to any one harness.
Two honest cautions. First, quality varies enormously in the public skill ecosystem. Community directories now index skills by the hundreds of thousands, and a February 2026 security audit that scanned 3,984 public skills found 36 percent carried at least one security flaw, including prompt injection payloads. A skill is instructions your agent will follow and sometimes scripts it will execute. Review community skills the way you review an open-source dependency, because that is exactly what they are. Second, a skill is not a capability grant. It tells the agent how to do something, not whether it is permitted to. If your permission model lives inside skill text, you do not have a permission model. You have a suggestion.
MCP connects an agent to tools. A2A connects an agent to other agents, and the distinction is easy to state: a tool is a passive capability you invoke, while a peer agent is an actor with its own reasoning, its own tools, and its own opinion about how to accomplish a task. Delegating to a peer is a different problem from calling a function, and A2A is the protocol built for it.
Google announced A2A in April 2025 and donated the specification, SDKs, and tooling to the Linux Foundation that June, where an independent project now governs it with backing from AWS, Cisco, Microsoft, Salesforce, SAP, ServiceNow, and others. By its first anniversary the project reported more than 150 supporting organizations and integrations across the major cloud agent platforms, with SDKs in Python, JavaScript, Java, Go, and .NET.
The mechanics center on two ideas. The first is discovery through Agent Cards. An A2A server publishes a JSON document at a well-known path describing what the agent can do, what skills it advertises, which transports it speaks, and what security it requires. A client agent reads the card and knows whether this peer can handle the task at hand. The second idea is the task lifecycle. A2A models delegated work as a task object that moves through explicit states: submitted, working, input required, auth required, and terminal states for completed, failed, canceled, and rejected. Long-running tasks stream status over server-sent events or push notifications, and the lifecycle survives disconnects.
The task lifecycle is the design decision that separates A2A from a fancy REST wrapper. Agent-to-agent delegation is slow, stateful, and frequently interactive. The peer agent works for minutes or hours, sometimes needs more input, sometimes needs the delegating side to authenticate, and sometimes fails halfway. Modeling all of that as first-class protocol state means both sides agree on where a piece of work stands without inventing a convention per integration.
Where does A2A fit next to the other five? It is the horizontal protocol in a stack of mostly vertical ones. MCP runs between an agent and its tools. Skills, profiles, and graphs are documents a single harness consumes. A2A runs between organizations, or between departments, wherever the two sides of a delegation do not share a runtime. That also defines its limits. Inside a single harness, spinning up A2A between your own subagents adds protocol overhead where a function call did fine. The fair criticism of A2A's first year was exactly that: enthusiastic architectures used it where simpler mechanisms served, and the protocol earned some skepticism it did not deserve on the merits. Use it at trust boundaries. Skip it inside them.
Now we reach the three specifications I authored, starting with the one that addresses the gap I felt most personally. Here is the problem in one paragraph. You spend months refining an agent: a code reviewer that knows your conventions, a data engineer that has learned your table layouts, a researcher that cites the way you want. That definition and everything it learned lives in one product, in that product's shape, and often only for the length of a session. The agent, as an artifact you own, does not exist.
The Open Agent Profile makes it exist by persisting the agent as a file. A profile is a YAML or JSON document with three top-level parts, and the boundary between them carries the whole design. Metadata holds the name, description, and a revision number. Spec holds the contract: role instructions, the model selection, the tool policy, permissions, and lifecycle settings. This is the part a human writes and approves. State holds what sessions learned: a summary, discrete facts with confidence and provenance, and open threads with status. This is the part sessions write. A harness reads the file, runs a fresh session, and writes an updated revision back when the session ends. Nothing stays resident. The file is the agent.
A portable file describing what an agent is permitted to do is a security problem before it is a convenience, and the spec's answer is three rules that hold under every configuration.
First, a profile narrows and never widens. A harness grants the intersection of what the profile requests and what its own policy already allows. There is no field or trust marker that reverses this, which means accepting a profile from a stranger is safe. The worst case is an agent with fewer capabilities than you already permit. Without this rule, portable agent files become an escalation mechanism: run a file from somewhere and receive whatever authority it claims.
Second, an agent cannot rewrite its own contract. Sessions emit a structured delta at the end, and delta operations only touch the state section. A change to tools, permissions, model, or instructions goes into a proposals block with a written rationale and waits for a human. This holds even under fully automatic writeback. A boundary that configuration can relax is not a boundary, just a default.
Third, learned state is untrusted content. Text an agent wrote about itself gets injected into future sessions as information, never as authority. A state entry claiming shell access no longer needs approval changes nothing. This rule closes the nastiest failure in persistent agents: without it, one successful prompt injection becomes permanent, because the attacker convinces the agent once and the agent writes the instruction into its own memory. Treating state as data keeps a one-time injection one-time.
The proposals mechanism deserves a paragraph because it solves the problem that kills least-privilege in practice. Narrow permissions fail socially, not technically: legitimate work gets blocked, friction builds, and someone widens the grant to stop the complaints. A proposal turns that pressure into evidence. When a session hits a wall, it records the specific change it needs and a rationale explaining what it was unable to do. A reviewer reads a request for shell access attached to an explanation that the agent was unable to verify a flaky test claim without running the suite, and makes an actual engineering decision. The mechanism produces the artifact a reviewer needs, at the moment the need is fresh.
The spec sits at version 1.0 with support libraries at 1.0.5 in Python, TypeScript, Go, Rust, and Java, all Apache licensed and tested against a shared conformance corpus that includes negative fixtures a correct implementation must reject. Profiles get canonical digests, so the exact content that was approved is verifiable regardless of encoding or field order. Three conformance levels let a harness be honest about partial support, from read-only instantiation up through full state persistence and composition, and an implementation is required to publish what it does not implement. Silent degradation is the failure that kills trust in portable formats: someone reviews a profile, runs it elsewhere, and gets a different agent than the one they read. I implemented OAP across my own harnesses, Loro and MagAgent, and in the Merced AI broker, so the spec has running code behind it, and I will be plain that adoption beyond that is early. The mitigating factor for you is that the artifact is declarative text describing your agents. If a different profile standard wins, translating files is a small job next to reconstructing agent definitions from a product UI.
Every serious harness already decomposes big jobs into steps. It does so internally, in its own shape, and the plan evaporates when the session ends. AGS makes the decomposition a document, and four familiar frustrations fall out of that one change.
You cannot review a plan you never see, so a wrong decomposition is discovered after the tokens are spent. You cannot move a plan trapped in one harness's memory, so the planning work is discarded at the session boundary. Without declared acceptance criteria, done is whatever the model says, and self-reported completion accumulates silent failures. And without a declared capability demand per step, every step gets the same model, which sends trivial work to expensive models and hard decisions to cheap ones.
An Agentic Graph is a directed acyclic graph where each node is a bounded agentic loop, one unit of work an agent runs end to end, and each edge is a control-flow dependency. The specification is implementation neutral, written in YAML or JSON with the two encodings equivalent, at version 1.0 under Apache 2.0 with libraries at 1.0.4.
The node is where the format earns its opinionated reputation. Each node declares a brief written to stand alone, so an agent that has seen nothing else can act on it. Typed inputs and outputs, so the harness checks that a node produced something of the right shape instead of trusting a claim. Success conditions, machine-checkable where possible and always human-readable, evaluated by the harness rather than asserted by the model. A normalized capability tier instead of a model name, so the graph stays valid when models are deprecated and portable to harnesses configured with different providers. Required tools, permissions, and budgets, declared per node. And failure handling, chosen from retry with feedback, fallback to an alternative approach, escalation to a stronger tier or different node, and human checkpoint.
Two structural elements lift this above a task list. Decision nodes branch on an outcome, ready or needs work, which lets a graph express remediation without becoming a cycle: the fix-it path rejoins downstream rather than looping back. Gates hold for an explicit human decision, and placing a gate immediately before the first irreversible action or the first expensive fan-out is the single highest-value structural choice in any graph.
The success-conditions rule carries the most weight, so let me defend it directly. A model asked whether it finished will usually say yes, not from dishonesty but because grading your own work against a criterion you also interpreted is unreliable. Systems built on self-reported completion rot quietly: a half-working step is reported done and the next step builds on it. Moving evaluation into the harness turns completion into a check. A condition stating that the test suite passes gets run. A condition that is only human-readable at least tells a reviewer what to look at, and an unchecked criterion still beats an unstated one.
A validated graph is also useful before anything runs. Planning tools derive execution order and parallelism, flag unreachable nodes, compute worst-case cost bounds when every retry path fires, summarize how much of the work demands an expensive tier, report which features this environment does not support, and produce a stable digest that ties a review to exact content. Knowing the worst-case bound before spending it is the difference between a budget and a hope.
The honest boundary: graphs cost structure, and structure applied everywhere makes an idea useless. Release processes, migrations, incident response, and multi-stage builds have real shape worth reviewing. Exploratory work does not. A question with unknown shape cannot be decomposed in advance, and forcing it into nodes produces a document that is wrong by step two. Explicit structure removes the room an agent has to improvise, which is precisely the point in high-consequence work and precisely the loss everywhere else.
The last of the six covers the smallest surface and, in production, one of the most consequential. Every harness eventually needs to and ask a person: the agent wants to run this command, send this email, drop this table. Approve or deny?
Today that handoff is almost always a terminal prompt blocking on standard input, which fails in every direction that matters at scale. The person is not at the terminal, they are on their phone. The process restarts and the pending question is gone. The approval UI is welded to one harness, so an organization running three harnesses builds three approval experiences. And the record of what was approved, if it exists at all, is a line in a log.
The Agent Approval Interchange Specification makes the approval itself a portable, durable protocol. AAIS 1.0 is a transport-neutral contract for one handoff: a runtime needs permission for an action, and a person decides from whatever trusted interface they are actually using, a CLI, a web page, a desktop app, or an automated policy service. It covers chats, subagents, background jobs, and graph nodes without defining any of those runtimes. Messages travel over whatever you have: MCP, HTTP with server-sent events, WebSocket, or stdio.
The design holds one line firmly: the harness stays the authority. A client presents the exact requested action and returns a selected decision. It cannot grant itself capability. Before acting, the harness revalidates the decision against current policy, the action digest, expiry, and the choices it originally offered. Four properties make the loop safe. Decisions bind to a canonical digest of the exact action reviewed, computed under RFC 8785 canonicalization, so what was approved is what runs, byte for byte in meaning. Choices are bounded, so a client only selects among scopes the harness offered. The lifecycle fails closed: expired, stale, conflicting, malformed, and replayed decisions are rejected. And requests carry provenance while retries stay idempotent, so the audit trail records who asked, for what, and what was decided.
Durability is the operational feature people feel first. A pending approval is application state, not a blocked process. Ordered events and snapshots let a browser or desktop client reconnect and recover outstanding decisions, including ones raised hours ago by a long-running graph node. The approval you did not answer at your desk is waiting on your phone.
AAIS ships as a 1.0 protocol with 0.1.0 support libraries in Python, TypeScript, Go, Rust, and Java, published to the standard registries and verified against shared fixtures so a message created in one language validates in another. It deliberately excludes chat, model reasoning, tools, and authentication, and it carries concise activity, risk, choices, decisions, and receipts rather than private chain-of-thought. Same disclosure as before: I wrote it, it is young, and the questions it answers stop being optional the moment agents act on systems that matter.
The composition story is where the stack stops being a list of acronyms and becomes an architecture, so let me trace one delegation end to end.
A profile defines your data engineer agent: its instructions, its permitted tools, its ceiling of authority, and everything past sessions taught it. A graph defines this week's migration: twelve nodes, typed handoffs, per-node budgets, a gate before the schema change. The harness loads both and grants each node the intersection of what the profile allows and what the node declares it needs, which yields per-step authority narrower than either document alone. Skills supply the procedures nodes follow, the migration checklist and the validation routine, loaded on demand. MCP supplies reach, connecting the agent to the warehouse, the catalog, and the ticketing system through servers those platforms publish. When node seven hits the gate, the harness emits an AAIS request, you approve the exact schema change from your phone an hour later, and the harness revalidates the decision before executing. When one node's brief calls for a legal review your organization delegates to another department's agent, the harness discovers that peer through its A2A card and hands off a task with a real lifecycle instead of a fire-and-forget API call.
Notice what the harness became in that story: an engine. Every artifact it consumed, the profile, the graph, the skills, the tool connections, the approval flow, and the delegation protocol, is a document or contract that outlives it. Swap the engine and the work moves. That is the whole thesis, and it is the same thesis open table formats proved in data: when the durable artifacts are specifications rather than internals, the runtime becomes a choice you revisit instead of a decision you married.
Abstractions earn trust when you see the files, so here is a trimmed but real-syntax pair: an OAP profile and an AGS graph fragment that references it.
oap_version: "1.0"
metadata:
name: code-reviewer
description: Reviews pull requests against team conventions
revision: 14
spec:
role: |
You review pull requests for correctness, style, and risk.
Flag anything touching auth or billing for human review.
model:
provider: anthropic
id: claude-opus-5
tier: frontier # portable fallback when the id is unavailable
tools:
mode: allowlist
allow: [git.read, files.read, tests.run]
lifecycle:
writeback: propose # state deltas apply, contract changes wait
state:
summary: Reviews Go and SQL. Team prefers table-driven tests.
facts:
- text: Migrations live in /db/migrations, numbered.
confidence: high
source: session-2026-08-12
pinned: true
threads:
- title: Flaky auth test on CI
status: open
proposals:
- change: add tool tests.run_integration
rationale: Unable to verify flaky-test claims from unit suite alone.
status: pending
Read the file the way a reviewer does. The spec block is the contract: an allowlist of three read-mostly tools plus test execution, a named model with a portable tier fallback, and writeback set to propose. The state block is what fourteen revisions of sessions accumulated, each fact carrying confidence and provenance so stale entries can be pruned, with one fact pinned to survive summarization. The proposals block shows the mechanism working: the agent hit a wall, documented it, and the request waits for a human. Nothing in state or proposals changed the contract.
ags_version: "1.0"
nodes:
- id: review
brief: >
Review the diff in inputs.diff against team conventions.
Produce findings as structured JSON.
agent_profile: code-reviewer # binds the OAP profile above
inputs: { diff: {type: fileset} }
outputs: { findings: {type: json} }
intelligence: { tier: standard }
success:
- check: outputs.findings validates against findings.schema.json
on_failure:
retry: { max: 2, feed_failure: true }
then: escalate
- id: gate-merge
kind: gate
brief: Human approves merge based on review findings.
edges:
- from: review
to: gate-merge
The review node runs at a standard tier because review does not need frontier capability, its success condition is a schema validation the harness executes, and its failure handling retries twice with the failure fed back before escalating. The gate holds for a person, and in a harness that speaks AAIS, that gate arrives on whatever device the approver is carrying. The two files together express who works, on what, with which authority, and where a human stands in the path, and neither file names the harness that will run them.
Standards do not remove failure. They move it somewhere visible, and knowing where to look is most of the operational skill.
Silent partial support. The failure that destroys trust in portable formats is a runtime that accepts a document and quietly ignores half of it. A harness that reads a profile at Level 1 does not persist state, which changes what the profile is for. A runtime that ignores a tool denylist turns a control into a description. Check the conformance statement of anything you depend on, and prefer implementations that publish their gaps over ones that look complete.
Injection through every content channel. MCP tool results, skill bodies, and profile state are all text that reaches the model, and all three have carried real attacks. The 36 percent flaw rate in that audit of public skills is the number to keep in mind when someone proposes installing community skills wholesale. The defenses stack: review skills like dependencies, pin MCP servers, treat profile state as untrusted by rule, and keep irreversible actions behind AAIS-style gates so injected intent still meets a human.
Stale documents. Profiles accumulate facts that stop being true. Graphs reference tools that got renamed. A confident agent running on stale declarations is worse than an ignorant one, because it acts. Prune profile state using the confidence and provenance fields, and validate graphs in continuous integration like any other artifact.
Over-decomposition. Twenty graph nodes where four serve produces coordination overhead and context loss at every boundary. A node is a unit of work an agent completes, not a single action. The matching mistake with skills is the mega-skill, a body so long the progressive-disclosure economics invert. Small, sharp, and few beats large and many in both formats.
Standards where they do not belong. A2A between your own subagents, graphs wrapped around exploratory questions, profiles stuffed with domain knowledge that belongs in a knowledge store: each is a real pattern I have seen proposed, and each adds ceremony without adding portability. The test is always the artifact: if nothing durable needs to move across a boundary, you do not need the interchange format at that boundary.
Budget surprises. Failure handling multiplies cost. A node with three retries, a fallback tier, and an escalation path is cheap on the happy path and expensive in the worst case. Plan against the worst-case bound the graph tooling computes, and let an alarming bound prompt the better question: does this node fail because the brief is unclear?
Reading the direction of travel is easier if you accept one premise: the agentic stack is recapitulating the data stack's history at roughly five times the speed. Formats standardize first, then catalogs and governance, then the engines commoditize. Skills standardized in weeks. MCP took about a year to become assumed infrastructure. A2A found its footing at trust boundaries after a year of being tried everywhere.
The unresolved layer is exactly the one OAP, AGS, and AAIS aim at: identity, work shape, and authority. Whether those particular documents win is the least interesting question. Watch instead for three signals. First, whether the major harness vendors expose import and export for agent definitions at all, because a vendor that will not let an agent leave has told you its answer on portability. Second, whether the institutional homes, the Agentic AI Foundation and the A2A project, expand scope to cover identity and approvals, which is the natural place for consolidation. Third, whether enterprises start requiring reviewable, digest-identified plans and approval receipts for agent actions in regulated workflows, because compliance demand is what turned data governance from a slideware topic into a purchase requirement, and the same forcing function is already visible for agents.
My own bet is on the pattern, not any single spec: durable artifacts as open documents, harnesses as replaceable engines, humans holding explicit gates. Every layer of infrastructure I have worked on eventually arrived at that shape. The ones that arrived early spared their users years of reconstruction work.
Six specifications, six questions. MCP answers what an agent can reach, and it is settled enough to build on without hesitation. Agent Skills answers what an agent knows how to do, and its cross-vendor adoption made procedural knowledge the first truly portable agentic artifact. A2A answers how agents cooperate across trust boundaries, with a task lifecycle built for slow, stateful, interruptible delegation. OAP answers who the agent is and what it has learned, with narrowing, contract protection, and untrusted state as its safety spine. AGS answers what shape the work takes, turning plans into reviewable, priceable, movable documents with harness-checked completion. AAIS answers how a human authorizes the moment that matters, durably, from any trusted surface.
Adopt them in the order your risk dictates. Tool connections and skills first, because the standards are mature and the wins are immediate. Then write one profile for your most capable agent, because writing down its authority surfaces at least one grant nobody defends. Then graph one process where a wrong plan is expensive. Gate the irreversible steps. At each stage, the test stays the same: when you imagine switching harnesses next year, what moves with you, and what do you rebuild? Every artifact in the second pile is a decision you have not finished making.
If this piece was useful, I have written a lot more on agentic architecture and the data foundations beneath it. Hands-On Agentic Engineering covers building multi-agent systems in practice, from harnesses and tool protocols to governance. You can find every book I have written, across lakehouse architecture, Apache Iceberg, Apache Polaris, and AI, at books.alexmerced.com.