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.

For over a decade, Code On Time has been the fastest way to build secure, database-driven applications for humans. The industry calls this Rapid Application Development (RAD). But recently, we realized that the rigorous, metadata-driven architecture we built for humans is also the perfect foundation for something much more powerful.

Today, we are announcing a shift in our vision. We are not just building interfaces for people anymore. We are evolving from a RAD tool for web apps into a RAD for the Digital Workforce. The same blueprints that drive your user interface are now the key to unlocking the next generation of autonomous, secure Artificial Intelligence.

The Digital Co-Worker (The "Glass Box")

Imagine an app that looks like Chat GPT. This app executes every prompt as if it is operating the "invisible UI" of your own database. Just like the human user, it inspects the menu options, selects data items, presses buttons, and makes notes as it goes. Then it reports back by arranging the notes into an easy-to-understand summary.

This is possible because a developer has designed the app with a real UI for your database. Both the DigitalI "Co-Worker" and the human UI are built from the exact same "blueprints" (called data controllers). These blueprints define the data, actions, and business logic for your application. When a user logs in (using their organization's existing security), the AI "digital employee" inherits your exact identity, meaning it sees only what you see and can only perform the actions available to you.

The AI "navigates" a system that has already been "security-trimmed" by user roles and simple, declarative SQL-based rules. This means if you aren't allowed to see "Salary" data, the AI is never shown the "Salary" option - it doesn't exist for that session. A "heartbeat" process allows these tasks to run 24/7, and the AI's "notes" (its step-by-step log) create a perfect, unchangeable audit trail of every decision it has made.

The Genius (The "Black Box")

Imagine another app that also looks like Chat GPT. To understand your database, this app employs a powerful, sophisticated AI model as its "brain". It operates by first consulting a comprehensive "manifest" - a detailed catalog of every "tool" and data entity it can access. This allows the AI to have a full, upfront understanding of its capabilities, so when you submit a prompt, it can process this entire catalog to create a complete, multi-step plan in a single "one-shot" operation.

This architecture is often built as a flexible, component-based system, which involves deploying several specialized services: one for the chat UI, another for the AI's "brain" (the orchestrator), and a dedicated "server" for each tool. Security is an explicit and granular consideration, requiring careful, deliberate configuration. Each tool-server's permissions must be managed, and the AI "brain" is trusted to orchestrate these tools correctly. This design allows for fine-tuning access (like "read/write all customer data") but means that security and prompt-based access must be actively managed and secured.

This "one-shot" planning model has a clear cost structure: the primary charge is for the single, complex "planning" call to the sophisticated "brain" model, which is required for every prompt. The success of the entire operation relies on the quality of this initial plan. If the AI's plan contains an error (for example, using incorrect database filter syntax) the operation may not complete as intended, and the cost of the "planning" call is incurred. This model prioritizes a powerful, upfront planning phase and depends on the AI's reasoning to be correct the first time.

How to Choose: The Auditable Co-Worker or the "Black Box" Genius

Your choice between the "Digital Co-Worker" and the "Genius" architecture is a strategic decision about what you value most: trust and durability or raw, unconstrained reasoning. The "Digital Co-Worker," built on the CoT framework, is an "invisible UI" operator. Its primary strength is its security-by-design. Because it inherits the user's exact, security-trimmed permissions, it is impossible for it to access data or perform actions it isn't allowed to. It operates within a "fenced-in yard" defined by your business rules. This makes it the perfect, auditable solution for the real-world workflows that require a quick response or need to run reliably for days or even months.

The "Genius" model, built on LLM+MCP, is a "one-shot" planner. Its primary strength is its power to reason over a massive, pre-defined database "map". It's designed for highly complex, one-time questions where the "planning" is the hardest part. This power comes at the cost of security and predictability; you are trusting a "black box" with a full set of tools, and its complex plans can be brittle, expensive, and difficult to audit. This model is best suited for scenarios where the sheer "intelligence" of the answer is more important than the security and durability of the process.

For a business, the choice is clear. The "Digital Co-Worker" is a platform you can build your entire company on. This is where it has a huge advantage: it can operate with a smart model for deep reasoning, but it also works perfectly with a fast, lightweight, and cheap model for 99% of tasks. The "Genius" model, by contrast, requires the most expensive model just to parse its complex manifest. Furthermore, the "Genius" model requires a massive upfront investment, potentially costing hundreds of thousands of dollars in custom development, integration, and security engineering before the first prompt is ever entered. The "Digital Co-Worker" platform, with its "BYOK" model and 100 free digital co-workers, makes it a risk-free, frictionless way to adopt a true workforce multiplier.

The Digital Co-Worker is Not a Chatbot

It is easy to mistake the "Digital Co-Worker" for a chatbot because they both speak your language. However, the difference is fundamental. As industry experts note, standard chatbots are "all talk and no action." They are engines of prediction, trained to guess the next word in a sentence based on frozen knowledge from the past. They can summarize a meeting or write a poem, but they are fundamentally passive observers that cannot touch your business operations.

The Digital Co-Worker is different because it is agentic. It is defined not by what it says, but by its ability to take actions autonomously on a person's behalf. When you give a chatbot a task, it tells you how to do it. When you give a Digital Co-Worker a task, it does it. It acts as an "autonomous teammate," capable of breaking down a high-level goal (like "review all pending orders and expedite shipping for anything delayed by more than two days") into a series of concrete steps and executing them without needing you to hold its hand.

This distinction changes the return on investment entirely. A chatbot is a tool for drafting text; a Digital Co-Worker is a tool for finishing jobs. It doesn't just help you draft an email to a client; it finds the client in the database, checks their order status, drafts the response, and with your permission, sends it. It moves beyond conversation into orchestration, bridging the gap between your intent and the complex reality of your database transactions.

The Co-Worker's "Glass Box": A Look Inside the HATEOAS State Machine

The "AI Co-Worker" operates by acting as a "digital human," using the application's REST Level 3 (HATEOAS) API as its "invisible UI." The entire process is driven by a built-in State Machine (SM). When a prompt is submitted, the SM's "heartbeat" processor wakes up. Its only "worldview" is the HATEOAS API response. It uses a fast, lightweight LLM (like Gemini Flash) to read the _links (the "buttons") and hints (the "tooltips") to decide the next logical step. As it works, it "makes notes" in its state_array, which serves as both its "memory" and a perfect, unchangeable audit log. This is how it auto-corrects: if an API call fails, the API returns the error with the _schema, which is just the next "note" in the log, allowing the AI to build a correct query in the next iteration.

This "glass box" model is inherently secure. The HATEOAS API is not a static catalog; it is "security-trimmed" by the server before the AI ever sees it. The app's engine uses declarative rules (like SACR) to filter the data and remove links to any actions the user isn't allowed to perform. If you don't have permission to "Approve" an order, the Digital Co-Worker will not see an "approve" link. The guardrails are not a suggestion; they are an architectural-level boundary, making it impossible for the AI to go rogue.

This architecture also enables true, durable autonomy. The "heartbeat" that runs the SM is designed to handle tasks that last for months. A user can "pause" or "resume" an agent simply by issuing a new prompt, as the AI can see and follow the pause link on its own "task" resource. Because the AI can also discover links to create new prompts (e.g., rel: "create_new_prompt" in the menu), a "smart" agent can decompose a complex prompt ("review 500 contracts") into 500 "child" tasks, which the heartbeat then patiently executes in parallel.

Beyond the Database: The Universal Interface

The power of the Digital Co-Worker extends far beyond the SQL database. The same "blueprints" (data controllers) that define your customer tables can also define "API Entities" (virtual tables that connect to external systems like SharePoint, Google Drive, or third-party CRMs).

To the AI, these external sources look exactly like the rest of the "invisible UI." It doesn't need to learn a new API, manage complex keys, or navigate different security protocols. It simply follows a link to "Documents" or "Spreadsheets" in its menu, and the application's engine handles the complex connection logic behind the scenes, presenting the external data as just another set of rows and actions.

This solves the single hardest problem in enterprise AI: secure access to unstructured data. Just like with the database, the system applies declarative security rules to these external sources. If a user is only allowed to see SharePoint files they created, the Digital Co-Worker will only discover those specific files. It enables a secure, federated search and action capability (allowing the AI to "read" a contract PDF and "update" a database record in one smooth motion) without ever exposing the organization's entire document repository to a "black box."

The Future is Built-In: Rapid Agent Development

The age of the expensive, brittle "Genius" AI is ending. The age of the secure, durable "Digital Co-Worker" has arrived. We believe that building a Digital Workforce shouldn't require a team of data scientists and six months of integration; it should be a standard feature of your application platform.

In our upcoming releases, we are delivering the tools to make this a reality. By simply building your application as you always have, you will be simultaneously architecting the secure, HATEOAS-driven environment where your Digital Co-Workers will live and work, powered by the Axiom Engine. Your database is ready to talk. Stay tuned for our updated roadmap - the workforce is coming under the full control and permission of the human user.