How a 25-year-old architectural standard solved the AI Agent problem before it even started.

For the last two years, the tech industry has burned billions of dollars trying to solve the "Agent Problem." How do we get AI to reliably interact with software?

We built massive vector databases. We trained 100-billion-parameter reasoning models. We invented complex protocols like MCP (Model Context Protocol).

But the answer wasn't in the future. It was in the past.

It turns out that Roy Fielding solved the Agent Problem in his doctoral dissertation in 2000. We just ignored him because we didn't have agents yet.

The "Level 3" Gap

In software architecture, we rely on the Richardson Maturity Model to grade our APIs.

• Level 2 (The Industry Standard): We use HTTP verbs (GET, POST) and resources. This works great for human developers who can read documentation and hard-code the logic into a UI.
• Level 3 (Hypermedia / HATEOAS): The API itself tells the client what it can do next.

For 25 years, the industry stopped at Level 2. "Why do I need the API to send me links?" a developer would ask. "I know where the buttons go."

But AI Agents are blind. They don't have the intuition of a developer. They need a map.

Validation from the Field

There is recent talk in the software architecture community that vindicates this "Level 3" approach. International speaker and software architect Michael Carducci recently delivered a session titled "Hypermedia APIs and the Future of AI Agentic Systems," where he articulates the precise architectural reality we have witnessed in our own labs.

Carducci argues that we don't need smarter models; we need "Self-Describing APIs." When an API includes the controls (Hypermedia) in the response, the AI agent no longer needs to guess, hallucinate, or rely on brittle documentation. It simply follows the path laid out by the server.

The Digital Co-Worker: Theory into Practice

Carducci’s talk represents the Theoretical Physics of Agentic AI. The Axiom Engine—embedded in every Code On Time application—is Applied Engineering.

When we generate a Digital Co-Worker, we are not building a chatbot with tools. We are building a Level 3 HATEOAS Browser powered by an LLM. This is made possible by a specific set of technologies we refer to as the Axiom Engine.

1. The Cortex: REST Level 3 & HATEOAS

The built-in engine automatically projects your application's User Interface logic into a RESTful Level 3 API. This is not a separate "AI API" that you have to maintain; it is a mirror of your live application.

Because it uses HATEOAS (Hypermedia as the Engine of Application State), the API response contains both the data and the valid transitions. When the Co-Worker processes an invoice, it reads the `_links` array in the JSON response. If the invoice is paid, the `pay` link physically disappears, and the `archive` link appears. The AI cannot click a link that isn't there.

2. The Pulse: Loopback & Heartbeat

Intelligence is useless without execution. The Axiom Engine includes a server-side Heartbeat that performs "Batch Leasing." It wakes up, checks for pending prompts, leases a block of work, and begins "Burst Iterating."

Crucially, every action is performed via an HTTP Loopback Request to the application itself. The State Machine executes these requests using the user's `access_token`, which is included and automatically refreshed via the `refresh_token` as needed. This architecture allows an agent to execute a prompt over the course of months. The server can restart, or the process can pause for weeks, but the agent's session remains valid and secure.

3. The Memory: Immutable Anchors & Dynamic State

Context is the most expensive resource in AI. To manage this, we use a collaborative memory model that balances flexibility with strict mission adherence:

• The Anchors (Positions 0-1): The User's Original Prompt and the System Instruction are permanently pinned to the first two positions of the state array. They are never compressed. This ensures that even after 100 iterations, the agent never forgets its core persona or its ultimate goal.
• The Dynamic Tail: For the subsequent history, the LLM decides the "next state to keep" in every iteration. It explicitly chooses what relevant information to carry forward.
• Intelligent Compression: The State Machine automatically compresses this dynamic tail based on configuration to keep the token count low, but it leaves the Anchors untouched.
• The Cycle: This allows the agent to move forward indefinitely using a hybrid context: the immutable mission (Anchors), the accumulated wisdom (Compressed Tail), and the current reality (HATEOAS Resource).

All prompt iterations are persisted in the app's CMS, enabling full auditability and traceability of the agent's "thought process."

4. The Continuum: Infinite Context & Real-Time Sync

Unique to the Axiom Engine is the ability to maintain an Infinite Meaningful Conversation that can span years.

• Sticky Context: A new prompt in an existing chat always starts with the Last Resource. If you finished talking about an Invoice last Tuesday, and type "Approved" today, the agent knows exactly which invoice you mean.
• JIT Refresh: The world changes while the agent sleeps. When a conversation resumes—whether after 5 minutes or 5 months—the State Machine automatically refreshes the "stale" resource. The agent always sees the live data (e.g., that the invoice was already paid by someone else), preventing "ghost" actions.
• Omnichannel Threads: This continuity works across all channels.
• • App: Supports multiple distinct chat threads.
  • SMS: Acts as a continuous, potentially year-long conversation stream.
  • Email: Each thread becomes a secure, long-term chat session.
• The "Menu" Fail-Safe: If the user changes the topic entirely (e.g., switching from Invoices to Sales), and the LLM cannot resolve the request against the current resource, it has a universal escape hatch: the "Menu" Link. This leads to the equivalent of the application's main navigation menu, complete with human-readable tooltips. The agent simply clicks "Home" and navigates to the new subject, just like a human user would.

5. The Badge: Identity & Security

In the Axiom Engine, Identity is paramount.

• OAuth 2.0 Authorization Code & Device Flow: Whether via web or "dumb" channels like SMS, every interaction is authenticated.
• Federated Identity Management: The engine integrates with corporate IdPs. The Digital Co-Worker has no separate identity; it is the user. It inherits the exact Row-Level Security (RLS) and Audit logs of the human it is assisting.

We Saved Millions by Looking Backward

While competitors are trying to build "Self-Driving Cars" by training better drivers (AI Models), we focused on building "Smart Roads" (Hypermedia Apps).

This architectural decision has saved us—and our clients—tens of thousands of dollars in R&D and implementation costs. We didn't need to invent a proprietary "Agent Protocol." We just needed to implement the standard that the web was built on.

The industry is currently scrambling to reinvent the wheel. Meanwhile, your database is ready to become an Agentic Operating System today. You just need to give it a voice.

... Hypermedia APIs and the Future of AI Agentic Systems - Michael Carducci …
This video features software architect Michael Carducci explicitly validating the Level 3 HATEOAS architecture as the critical enabler for autonomous AI systems, mirroring the exact technical strategy of the Axiom Engine.