Agent-Native Architecture: Software Agents Can Operate

What Is Agent-Native Architecture?

Agent-native architecture describes software an AI agent can drive end to end on its own, without a person clicking anything on its behalf. That definition has four parts because an agent works as a loop: it picks an action, calls it, reads the result, and decides what to do next. Each property keeps one step of that loop running, which is why dropping any single one stalls the whole run.

The distinction matters because agent adoption is still shallow. The 2025 Stack Overflow Developer Survey found that only 31% of developers currently use AI agents, 17% plan to, and 38% have no plans to adopt them at all. Software that agents cannot operate is one reason the ceiling is where it is.

The same reasoning drives how multi-agent AI systems pass work between components, where one agent's output has to be another agent's parseable input. An interface too loose for a second agent to consume is the same defect, one layer up.

Agent-Native vs AI-Enabled vs API-Wrapped

Most products that claim agent support fall into one of the first two columns. The difference shows up the moment an agent tries to complete a task nobody scripted for it in advance.

API-wrapped is the column teams overestimate. A complete REST API still fails an agent if the response is an HTML success page, if nothing enumerates the available operations at runtime, or if the write path has no matching read path. This is the same structural gap that agent-first development runs into when a coding agent ships code it cannot verify.

The Four Properties an Agent Needs

Each property maps to one step of the agent loop. Drop any one and the loop stops at that step.

Discoverability is the one teams skip most often, because a human never needs it. A person learns your product once and remembers. An agent starts every session with no memory of your interface and has to be told what exists.

Why Dashboard-Only Capabilities Are Invisible

A capability that exists only behind a dashboard click has no callable entry point. The agent is not choosing to ignore it. The feature is not part of the surface the agent can reach, so it never enters the agent's set of options at all.

This produces a specific and confusing failure: the agent completes most of a workflow, then stops at the step that only exists in the UI. To the user it looks like the agent gave up. What actually happened is that the workflow had a gap the agent could not cross.

• Bulk actions - Selecting rows and applying an operation is trivial in a table UI and frequently has no equivalent single call behind it.
• Settings toggles - Configuration that only a settings screen can change forces the agent to ask a human mid-task.
• Export and download - A button that streams a file to the browser gives the agent no path to the same bytes.
• Confirmation dialogs - A destructive action gated by a modal has no programmatic equivalent for confirming intent.

The fix is not to expose everything at once. Start by tracing one real workflow end to end and listing every step that has no call behind it. That list is your agent-native backlog, ordered by how often the workflow runs.

Note: Kane CLI from TestMu AI runs the same natural-language objective from a developer's terminal, from CI, and from inside an AI coding agent's loop, using one binary and one syntax. Try it free!

Designing Output an Agent Can Parse

A human-readable report is a rendering decision. An agent needs the data underneath it, in a shape that does not change when someone improves the formatting. The working pattern is one JSON object per line, each with a typed field naming the event, ending in a terminal event that carries the full result.

Kane CLI is built this way. It exposes three modes selected by flags rather than separate binaries: an interactive terminal UI for a developer debugging a flow, a headless mode for shell scripts, and an agent mode that suppresses the UI entirely and emits NDJSON on stdout. A trimmed run looks like this, with the run_end fields cut down to the ones that matter here; the Kane CLI agent mode documentation covers the full event schema, including the extracted values, token usage, and run directories the real event also carries.

{"type":"run_start","objective":"Verify checkout","timestamp":"2026-04-30T10:30:45Z"}
{"type":"step_start","index":0,"objective":"Navigate to cart page"}
{"type":"step_event","index":0,"event":"action","detail":"Navigated to /cart","success":true}
{"type":"step_end","index":0,"status":"passed","duration":2.3,"summary":"Navigated to cart"}
{"type":"run_end","status":"passed","summary":"...","duration":45.2}

The shape is what makes it usable. A caller that only wants the verdict reads the last line and stops. A caller that wants progress consumes the stream as it arrives. Neither has to understand the other's use case, and improving a human-facing summary does not break either one.

Pair the stream with standard process exit codes so a pipeline can branch without parsing anything. Kane CLI returns 0 for a passed test, 1 for a failed assertion, 2 for an error such as an auth failure or browser crash, and 3 for a timeout or cancellation. Separating a failed assertion from a broken environment is the distinction that lets an agent decide whether to fix the code or retry the run.

Where the Human Gate Belongs

The Model Context Protocol specification states that hosts must obtain explicit user consent before invoking any tool, and that users should understand what each tool does before authorizing its use. It also notes that MCP itself cannot enforce these principles at the protocol level, leaving them to implementors.

That combination is why placement is a design decision you own. The requirement to get consent is settled; where in the run you collect it is not.

What you control is where that consent is collected. Approving every individual action turns the agent into an expensive click-confirm loop. Approving a finished artifact keeps the loop running and still puts a person on the destructive decision.

• Late gate, at review - The agent produces a complete artifact, a person reads it once and approves. Correct for generation, drafting, and analysis.
• Mid-loop gate, per action - Justified only where a single action is irreversible and high-stakes, such as deleting production data or moving money.
• Blast-radius scoping - Give the agent credentials that cannot perform the actions you would have blocked anyway, so the gate is enforced by permissions rather than by attention.

Scoping matters more than gating. A prompt asking a human to confirm is a control that fails whenever the human is tired; a credential that lacks delete permission is a control that does not. The tradeoffs of removing the human from the inner loop are covered in depth in human-out-of-the-loop testing.

On the transport question, a CLI is usually the faster first step because it is one binary that works in CI and in any agent's shell. An MCP server adds runtime capability discovery, which is the property a CLI's help text only approximates. The practical order is to ship the CLI, stabilize the command surface, then wrap it, as discussed in MCP and AI agents.

How to Test an Agent-Native System

The properties above are contracts, and contracts drift. A UI-focused change can rename a typed field, drop an action from the discovery list, or turn a clean exit code into a generic failure, and every one of those passes a conventional test suite while breaking every agent downstream.

Teams are also monitoring agents with tools built for human-paced operations. Stack Overflow's write-up of the 2025 survey reports that developers are adapting their existing monitoring tools for agentic AI observability, naming Sentry at 32% and New Relic at 13%, both of which have been around for 20 or more years.

Four assertions cover the contract:

• Capability discovery returns the expected set of actions, and each one still declares the input schema the agent was built against.
• The output schema holds, so every typed field the agent reads is present, named the same, and carrying the same type.
• Exit codes still map to their documented outcomes, including the distinction between a failed assertion and a broken environment.
• A scoped credential is refused when it attempts an action outside its blast radius.

The other half is running the agent against a real environment. For this article we opened a real Browser Cloud session from TestMu AI, pointed it at the Selenium Playground, and had it enumerate what a caller could actually reach on the page. The run emitted the events below, reporting 237 discoverable link actions. Alongside them the cloud adapter logged the session to a real build record at automation.lambdatest.com/test?build=102420711, which is where the run is replayable:

{"type":"session_start","session_id":"session_1787678557761_6mirv4","adapter":"playwright","t":"0.0"}
{"type":"action","detail":"navigated","url":"https://www.testmuai.com/selenium-playground/","success":true,"t":"15.7"}
{"type":"observation","field":"title","value":"Selenium Grid Online | Run Selenium Test On Cloud","t":"15.8"}
{"type":"observation","field":"discoverable_actions","count":237,"t":"15.9"}
{"type":"artifact","kind":"screenshot","bytes":88019,"t":"16.2"}
{"type":"run_end","status":"passed","duration":16.155,"t":"16.2"}

The rendered page listed capabilities a human could see, and the enumeration returned what an agent could actually call. Holding those two counts against each other is the test: when the page shows a capability the enumeration does not return, that capability just became invisible to every agent operating the product.

Running that check at scale needs infrastructure shaped for agents rather than for one human watching one tab. Browser Cloud provisions real Chrome sessions on demand, reaches localhost and staging through a built-in tunnel, and keeps sessions observable instead of opaque, which is what makes a failed agent run debuggable. Tracing what the agent did across a full run is the subject of agent observability.

Retrofitting an Existing Product

A rewrite is rarely the answer. The properties are independent, so they can land one at a time, each one making a real workflow more agent-operable than it was.

Do them in that order. Discovery built on an unstable command surface has to be rebuilt every time the surface moves, which is why the MCP layer belongs last rather than first.

Note: Browser Cloud from TestMu AI gives AI agents real Chrome sessions on demand, with a built-in tunnel to localhost and staging and full session transparency for debugging. See the Browser Cloud quick actions to scrape, screenshot, or capture a PDF in a single call.

Conclusion

Pick the workflow your users run most and trace it as an agent would: list every step that has no call behind it, every result that comes back as prose, and every write with no matching read. That list, ordered by frequency, is the whole project.

Then verify the contract rather than assuming it. Run the workflow against a real environment, assert that discovery, output schema, exit codes, and permission scoping all still hold, and keep those assertions in CI where a UI change will trip them. The Browser Cloud session lifecycle documentation is the place to start if you are wiring that check into a pipeline.