Protocol Over Prompts: Why ANX Rewrites the Rules of AI Agent Interaction

Forms are boring until an AI agent has to fill one.

Then the boring form becomes a surprisingly expensive machine. The agent reads the page, interprets the fields, finds the dropdowns, waits for the browser, loads dynamic options, decides what to click, serializes actions, and tries not to leak whatever the user typed into the wrong place. This is not intelligence in the glamorous sense. It is office work wearing a robotic costume.

That is exactly why the ANX paper is more interesting than its surface topic suggests. ANX is not mainly about making form filling faster. It is about a larger design claim: AI agents should not interact with digital systems by pretending to be humans, and they should not carry every tool description, option set, sensitive input, and execution decision inside the language model context. They need a protocol pipeline.¹

The paper proposes ANX, or AI Native eX, as a protocol-first framework for agent interaction. Its core package includes ANX Markup, ANX Config, ANX CLI, dynamic discovery through ANXHub, and structured SOP expression. Around that protocol, the paper introduces a 3EX architecture: Expression, Exchange, and Execution. The basic idea is simple enough to fit on a whiteboard, which is always suspiciously good news: describe the task cleanly, discover the right tool only when needed, and execute outside the model through a structured runtime.

That simplicity is also the point. The business mistake is to treat every agent failure as a model capability problem. In many workflows, the problem is that the system gives the agent the wrong job. It asks the LLM to read screen clutter, load interface details, handle sensitive user data, choose tools from long schemas, and perform execution planning in one crowded context window. Then everyone acts surprised when the agent becomes slow, costly, and occasionally creative in the least helpful way.

ANX’s contribution is to move some of that burden out of the prompt and into the interaction architecture.

The wrong baseline is a very smart agent staring at a human interface

The familiar approach to digital agents is GUI automation. A browser opens. The agent sees something like a user would see. It parses the page, identifies fields, clicks buttons, types text, and submits. This has one obvious advantage: websites already exist. No new protocol is required. The agent can use the world as humans built it.

That advantage is also the trap.

Human interfaces are optimized for human perception, not for machine execution. They carry layout, visual hierarchy, labels, DOM structure, interaction state, and plenty of irrelevant noise. A person glances at a form and understands it. An LLM agent often needs a long textual reconstruction of the page plus step-by-step browser actions. The agent is not using the application. It is performing a theatrical imitation of a user.

MCP-style tool calling improves the situation. Instead of reading the screen, the agent can call a structured tool. The tool has a schema. The model supplies arguments. The backend executes. That is better than asking an agent to hunt for the “Submit” button like a confused intern in a browser window.

But the paper argues that MCP-style systems remain tool-centric rather than protocol-centric. They still often require pre-registration, local tool exposure, schema loading, and direct handling of dynamic option sets. If a form includes remote dropdown values, those values may still need to be fetched and placed into the model-visible tool context. The agent is no longer trapped in the browser, but it is still carrying too much operational furniture in its prompt.

ANX tries to change the unit of design. Instead of asking, “How can we help the LLM use this interface?” it asks, “What should an agent-native interaction look like if the interface, discovery process, execution layer, and security boundary are designed together?”

That shift matters because enterprise automation is not a benchmark game of one-off cleverness. It is repeated interaction under cost, latency, audit, security, and workflow constraints. In that environment, a slightly smarter model is useful. A better interaction contract may be more useful.

ANX separates the job into Expression, Exchange, and Execution

The paper’s mechanism-first argument lives in the 3EX architecture.

The Expression layer describes what needs to be done. ANX Markup encodes fields, validation rules, interaction elements, and security annotations. ANX Config provides a shared configuration format for applications or SOPs. This is where the paper’s “protocol over prompts” logic begins. A task should not be a pile of natural-language instructions that the model must reinterpret every time. It should have a structured form that both humans and agents can work with.

The Exchange layer handles discovery. ANXHub is presented as a semantic marketplace where agents retrieve relevant ANX applications on demand. The paper contrasts this with local or pre-registered tool lists. The claimed benefit is progressive disclosure: the agent should receive only the relevant tools for the current task, not a kitchen drawer of schemas just in case it might someday need a corkscrew.

The Execution layer then runs the interaction. ANX Core parses the structured task specification, converts it into platform-agnostic ANX CLI commands, and passes execution to ANX Nodes. The model does not need to simulate browser interactions or manually carry dynamic options through a JSON payload. It can specify the task; the runtime handles the mechanics.

This is the central mechanism: ANX reduces cognitive and token load by deciding which responsibilities belong in the model context and which belong in the protocol runtime. The model still matters. It can express intent, select branches, and coordinate with structured feedback. But it is no longer asked to be browser, schema registry, dropdown cache, password manager, and workflow scheduler at the same time.

There is a useful business analogy here. A good enterprise system does not ask a manager to personally walk invoices between departments because “humans are flexible.” It defines fields, permissions, routing rules, approval gates, and logs. Flexibility remains, but it is bounded by structure. ANX applies that boring enterprise wisdom to AI agents. Boring, in this case, is a compliment.

The paper’s experiment tests efficiency, not the whole ANX vision

The empirical section is narrower than the architecture. That is not a flaw, but it must be read correctly.

The paper evaluates three methods on a job account registration form: GUI-based automation, an MCP-based job form skill, and ANX. The task has 10 fields and two dynamic option fields loaded via URL. Sensitive handling is disabled. There is no multi-skill invocation, no SOP workflow, and no sensitive data handling in the experiment. The framework is OpenClaw Agent in Docker, with a 13.2k-token baseline consumed by system prompts and core skills before task-specific execution. The authors run 30 repetitions per method per model, using Qwen3.5-plus and GPT-4o.

That means the result tables should be treated as main evidence for efficiency in a medium-complexity form-filling task with dynamic options. They should not be treated as direct validation of ANX’s security model, multi-agent SOP orchestration, global marketplace reliability, or enterprise-scale governance. Those are architecture claims and future-work targets. The distinction is not pedantry; it is the difference between reading a paper and turning it into a sales deck with better fonts.

This reading matters because ANX’s strongest validated result is not “we solved enterprise agents.” It is more precise: when the task contains dynamic interface information that otherwise bloats the model context, moving resolution into a structured runtime can materially reduce tokens and latency.

That is already useful.

The numbers show where the tokens were hiding

For Qwen3.5-plus, the task-incremental token use is 9.1k for GUI automation, 7.4k for MCP-based Skill, and 3.9k for ANX. Execution time is 33.2 seconds for GUI, 30.8 seconds for MCP, and 12.9 seconds for ANX.

For GPT-4o, the task-incremental token use is 8.3k for GUI, 6.3k for MCP, and 2.8k for ANX. Execution time is 48.2 seconds for GUI, 39.0 seconds for MCP, and 16.5 seconds for ANX.

The headline reductions are substantial: ANX reduces task-incremental tokens by 47.3% for Qwen3.5-plus and 55.6% for GPT-4o compared with the MCP-based skill. Compared with GUI automation, the reductions are 57.1% and 66.3%. Execution time also drops sharply: the paper reports 58.1% and 57.7% reductions versus MCP-based skill for the two models.

The interpretation is more important than the arithmetic. GUI automation is expensive because the model must process and act through a human-facing interface. MCP is cheaper because it exposes a tool schema, but it still requires the model to handle dynamic options in the tool-call payload. ANX is cheaper because the markup can point to the dynamic dataset, while ANX Core resolves the options during execution.

So the token saving is not magic compression. It is responsibility relocation.

That is the practical insight. Many agent systems burn tokens not because the task is semantically hard, but because the system architecture forces the model to carry runtime details. A dropdown list is not strategic reasoning. A DOM tree is not business intelligence. A confirmation button is not cognition. When those details enter the context window, the organization is paying reasoning prices for plumbing.

ANX says: stop putting the plumbing inside the prompt.

The security idea is stronger as an architecture boundary than as an experiment

The most business-relevant part of ANX may be its treatment of sensitive data, even though the experiment does not test it.

The paper proposes UI-to-Core sensitive data isolation. Fields marked as sensitive in ANX Markup trigger an ANX UI component that communicates directly with ANX Core. The LLM receives only a non-sensitive reference token. In principle, the user can enter a password, financial credential, or other sensitive value without placing the raw value inside the model context.

The paper also proposes human-only confirmation. Sensitive operations enter a CONFIRMING state with no programmatic exit. A trusted dialog obtains and manages a User Token invisible to the LLM; execution proceeds only after valid human interaction. The goal is to prevent an agent from simulating approval for high-risk actions.

This is an important correction to a common misconception. Some readers may see ANX and think, “Fine, another tool schema.” That misses the point. ANX is trying to define where the model is allowed to see, decide, and act. A tool schema tells the model how to call a function. A protocol boundary tells the system what the model must not touch.

For enterprise deployment, that boundary is not decorative. It affects vendor risk, auditability, compliance, incident response, and user trust. If sensitive data routinely enters the LLM context, then every downstream logging, retention, debugging, tracing, and vendor-processing decision becomes more dangerous. If the model can approve its own critical operation, then “human-in-the-loop” becomes theater. Very elegant theater, perhaps. Still theater.

ANX’s proposed answer is to make sensitive input and high-risk confirmation structurally non-delegable.

But the boundary must be stated cleanly. The paper itself acknowledges that ANX does not defend against unvalidated dialog credibility, tampered ANX Core, non-official ANXHub, or LLM-induced social engineering where the model persuades a user to paste sensitive information directly into chat. In other words, ANX can reduce one class of model-context leakage, but it does not abolish trust engineering. The protocol needs trusted runtime components, credible UI verification, hub governance, and user education.

The business lesson is not “ANX makes agent security solved.” It is better: security should be designed into the interaction pathway, not pasted on after the agent has already seen the secret.

SOPs are where the architecture becomes more ambitious

The paper’s SOP discussion extends ANX from single interactions to long-horizon workflows.

ANX SOP uses structured markup to define steps, conditional logic, operation standards, field constraints, dependencies, and routing targets. The paper gives a resume-screening example: one step parses resume data, another computes or evaluates a matching score, high-confidence cases can proceed automatically, low-confidence or boundary cases can trigger manual HR review, and follow-up actions such as interview scheduling or decline messages can be assigned to an action agent.

The design uses sources and targets. Sources establish predecessor dependencies. Targets define candidate next steps for dynamic routing. Joining behavior can be controlled so that a step waits for all relevant sources or proceeds when any source completes. This is exactly the kind of structure missing from prompt-only SOPs, where the “workflow” often means a long instruction paragraph and a quiet prayer.

The mechanism is valuable because enterprise workflows are not just sequences. They contain dependencies, exceptions, blocking approvals, branching logic, evidence handoffs, and role boundaries. Natural language can describe these things, but it does not enforce them. A protocol can.

Still, this part of the paper is mainly an architecture proposal and case illustration. The experiment does not measure a 50-step SOP, multi-agent coordination under failure, approval latency, branching correctness, or audit-trace completeness. The SOP section should therefore be used as a design lens rather than empirical proof.

For Cognaptus readers, the useful question is not whether ANX’s exact syntax becomes the standard. The useful question is whether future agent workflows will be governed by prompt instructions or by structured process specifications. In serious operations, the latter is the more plausible direction. Prompts are excellent for interpretation. They are less excellent as compliance infrastructure.

What ANX changes for enterprise automation design

The paper points toward a practical design pattern for AI automation vendors and internal enterprise teams.

First, reduce screen dependence where possible. GUI automation remains useful for legacy systems that expose no better interface. But when businesses control the workflow, designing an agent-native interaction layer is likely cheaper than making agents repeatedly parse human screens. A human-readable UI and an agent-executable specification can be generated from the same protocol object. That is a more scalable path than asking agents to cosplay as office staff forever.

Second, keep dynamic operational data out of the model context unless the model truly needs it. The experiment’s dynamic-option fields are a small example with a large implication. If option sets, catalogs, policy tables, validation rules, or reference lists can be resolved by the runtime, the LLM should not carry them all. Context windows are for reasoning-relevant information, not for hauling every dropdown value like a moving truck.

Third, separate discovery from execution. A tool marketplace or hub should retrieve the relevant application or skill only when needed. Preloading every possible tool makes agent prompts heavy and brittle. On-demand discovery introduces its own governance challenges, especially around trust and supply-chain safety, but the architectural direction is sensible.

Fourth, turn human approval into a protocol state, not a polite suggestion. In high-risk workflows, approval should be a blocking state with a human-only completion path. “Please ask the user before doing this” is not the same as a runtime that prevents programmatic completion. One is a norm. The other is a control.

Fifth, treat SOPs as executable structures. Many companies already have SOP documents. They are often written for training, audit, or managerial comfort. Agent execution requires something more formal: dependencies, conditions, roles, data contracts, allowed actions, and confirmation gates. ANX’s SOP proposal shows one possible route.

The broader ROI relevance is not only lower token bills. Token cost is the easiest number to see, so naturally everyone stares at it. But the more durable value may come from lower integration friction, shorter execution time, fewer ambiguous handoffs, clearer audit logs, and reduced exposure of sensitive data. Cost savings are nice. Not accidentally giving the model the payroll credentials is also a charming feature.

The strongest business reading is architectural, not benchmark-driven

A benchmark-first reading says: ANX used fewer tokens than GUI and MCP on a form task.

A stronger business reading says: the result illustrates a general cost pattern. When agent systems push interface interpretation, tool discovery, dynamic data loading, and execution control into the LLM context, they pay for operational clutter as if it were reasoning. ANX reduces that clutter by moving it into a protocol runtime.

That distinction helps avoid two bad conclusions.

The first bad conclusion is overclaiming. ANX has not yet proven large-scale enterprise stability, adversarial security, multi-agent orchestration, or cross-platform dominance. The paper is explicit that security evaluation, multi-step SOP evaluation, ANXHub comparison, enterprise hub deployment, compute-intensive scenarios, traceability, and lightweight specialized models remain future work.

The second bad conclusion is under-reading. A narrow experiment does not make the architecture irrelevant. Many important systems begin with a small empirical demonstration of a mechanism. Here the mechanism is clear: structured markup plus decoupled execution can cut token and latency overhead by removing unnecessary runtime details from the language model context.

For builders, that is already actionable. You do not need to wait for a universal ANX ecosystem to apply the design lesson. In your own agent stack, ask four questions:

This is where ANX becomes more than a proposed protocol. It becomes a useful critique of prompt-heavy agent design.

Boundaries before adoption: what remains uncertain

The paper’s limitations are not minor footnotes. They define the adoption boundary.

The experiment covers one medium-complexity form-filling scenario. It is repeated carefully, but it is still one scenario. It does not show how ANX behaves under broad enterprise task diversity, unstable external services, high concurrency, unreliable networks, adversarial tool listings, permission conflicts, or long-running stateful workflows.

Security is architecturally specified but not systematically attacked. The UI-to-Core and human-only confirmation mechanisms are promising, but real deployments would need adversarial tests: spoofed dialogs, compromised Core components, malicious hubs, misleading tool metadata, social engineering through the LLM, and logging leakage outside the primary model context.

ANXHub is conceptually powerful but operationally heavy. A global or enterprise skill marketplace raises governance questions. Who signs skills? Who reviews updates? How is trust inherited across hubs? How are malicious or stale tools removed? How is semantic discovery evaluated when two tools look similar but one has a dangerous side effect? The paper identifies future work around weakly decentralized enterprise ANXHub deployment, which is the right direction, but the hard governance questions remain.

The SOP vision is also under-tested. Structured workflows can improve determinism, but long-horizon enterprise processes fail in ways that are not purely syntactic: missing data, conflicting policies, unclear accountability, human delay, exception escalation, and changing business rules. ANX Markup can represent a process; it cannot guarantee that the organization has designed a good one. Sadly, no protocol has yet automated managerial clarity.

These boundaries do not weaken the article’s core interpretation. They keep it honest. ANX is best read as a strong architectural proposal with an efficiency demonstration, not as a fully validated enterprise agent operating system.

The future of agents may look less like chat and more like process control

The uncomfortable lesson of ANX is that natural language alone is too loose for many business operations.

That does not mean LLMs become unimportant. The opposite is more likely. LLMs remain useful for interpreting intent, generating structured specifications, making bounded decisions, summarizing evidence, and handling exceptions. But the better the surrounding protocol, the less the model has to waste attention on mechanics. The agent becomes more useful not because it talks longer, but because the system stops asking it to talk its way through everything.

This is the same shift seen in mature software systems. Early automation often begins with scripts and manual workarounds. Mature automation develops contracts, schemas, queues, permissions, logs, and state machines. AI agents are now going through their own version of that transition. Prompting was the quick bridge. Protocols may be the infrastructure.

ANX’s exact format may or may not become widely adopted. The paper’s lasting point does not depend on that outcome. Its real contribution is to make a design principle visible: enterprise agents need interaction layers that are native to agents, safe for humans, and structured enough for operations.

If the next generation of agents is still staring at screens, reading giant prompts, and carrying passwords through model context, then we have not built intelligent automation. We have built a very expensive browser intern.

Protocol-first design is less glamorous. It is also much closer to how serious automation survives contact with real business.

Cognaptus: Automate the Present, Incubate the Future.