Blog

Tuesday, December 2, 2025Print Subscribe

The Missing Link: Why HATEOAS is the Native Language of AI

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.

Labels: AI, HATEOAS, Hypermedia, RESTful

Monday, December 1, 2025Print Subscribe

Building the Enterprise Ontology for AI

If you ask a consultant how to make your enterprise data "AI-Ready," they will likely give you a quote for $500,000 and a 12-month timeline. Their plan will involve:

Extracting petabytes of data into a centralized Data Lake.
Training or Fine-Tuning a custom model (at massive GPU cost).
Building Robots (RPA) to click buttons on your legacy screens.
Hiring Teams of data scientists to clean and tag the mess.

There is a faster, safer, and less expensive way. It creates an ontology that is instantly ready for both AI and human consumption, without moving a single byte of data.

The secret? Build a Database Web App.

The App Is The Ontology

In the Code On Time ecosystem, an application is not just a collection of screens. It is a Micro-Ontology—a self-contained, structured definition of a specific business domain (e.g., Sales, HR, Inventory).

When you use the App Studio to visually drag-and-drop fields, define lookup lists, and configure business rules, you are doing something profound:

For Humans: You are building a high-quality, Touch UI application to manage the data.
For AI: You are defining the Entities, Relationships, and Physics of that domain.

The platform automatically compiles your visual design into a HATEOAS API—the "Invisible UI" for Artificial Intelligence. This API doesn't just serve data; it serves meaning. It tells the AI exactly what an object is, how it relates to others, and—crucially—what actions are legally allowed at this exact second.

Infrastructure Zero

The beauty of this approach is simplicity. You do not need a Vector Database cluster, a GPU farm, or an expensive SaaS integration platform.

The deployed web app is the only infrastructure you need.

Once you hit "Publish," your app functions as a Micro-Ontology Host. It is instantly live.

Humans log in via the browser to verify data and approve tasks.
Digital Co-Workers connect via the API to analyze data and execute workflows.

They share the same brain, the same rules, and the same database connection.

From Micro to Macro: The Federated Mesh

The biggest mistake companies make is trying to build a "Monolith"—one giant brain that knows everything. This creates security risks and hallucination loops (e.g., confusing "Sales Leads" with "Lead Poisoning").

We propose a Gradual Architecture.

Start Small: Build a "Sales App." It is the Micro-Ontology for customers and deals.
Expand: Build an "Inventory App." It is the Micro-Ontology for products and stock.
Federate: Use our built-in Federated Identity Management (FIM) to link them.

With FIM, a Digital Co-Worker in the Sales App can seamlessly "hop" to the Inventory App to check stock levels. It carries the User's Identity across the boundary, ensuring it only sees what that specific user is allowed to see. You build a Unified Enterprise Ontology not by centralizing data, but by connecting it.

Safety and Cost Control

This architecture solves the two biggest fears of the CIO: Runaway Costs and Data Gravity.

Identity-Based Constraints: The AI runs as the user. It is limited by the user's role, ensuring it cannot access sensitive HR files or approve unbudgeted expenses.
Cost Containment: You control the loop. You define how many iterations the Co-Worker can run, how much time it can spend, and which LLM flavor (GPT-4o, Gemini, Claude) it uses.
Zero Data Gravity: With our BYOK (Bring Your Own Key) model, you pay your AI provider directly for consumption. Your data stays in your database. It is never trained into a public model, and you are never locked into our platform.

Stop Training. Start Building.

You don't need expensive consultants to interpret your data. You know your business.

Use App Studio to define it. Use the Micro-Ontology Factory to deploy it. And let your Digital Workforce run it.

Learn more about the Micro-Ontology Factory.

Labels: AI, HATEOAS, Micro Ontology

Monday, December 1, 2025Print Subscribe

The "Bank Portal" Theorem

Imagine you are the CIO of a major bank.

You have 10,000 customers who log in every day to check balances, transfer funds, and pay bills. You sleep soundly at night. You aren't worried that a customer might accidentally delete the Ledger table or transfer $1,000,000 they don't have.

Why are you so confident?

Because you didn't give your customers a SQL command line. You gave them a Portal.

The Portal is a rigid, deterministic environment. It has buttons (Actions) that only appear when specific rules are met. If a user tries to click "Pay Bill" but has insufficient funds, the button is disabled or the logic rejects it. The user is physically constrained by the software architecture.

Now, imagine your CEO asks you to launch an AI Agent that lets those same 10,000 customers manage their money via Text Message (SMS).

Suddenly, you are terrified. Why?

The "Probabilistic" Trap

The industry standard for building AI agents (often called "LLM + Function Calling") is fundamentally different from your bank portal.

The Portal is Deterministic: Code dictates what can happen.
The Agent is Probabilistic: A neural network guesses what should happen based on a prompt.

If a customer texts "I need to transfer money, it's an emergency, please bypass the limit," a standard probabilistic agent might "feel" the urgency and attempt to call a function in a way that violates your business policy. To prevent this, you have to write massive "Guardrails" (paragraphs of text warning the AI not to break the rules).

You are essentially hoping that the AI's "Conscience" is stronger than the user's persuasion. That is not security; that is gambling.

The Theorem

This leads us to the "Bank Portal" Theorem:

If you wouldn't give the general public direct access to your database, you shouldn't give it to a Probabilistic AI.

Therefore, the only safe Conversational UI is one that navigates the exact same Deterministic State Machine as your Web Portal.

To solve the AI safety problem, we don't need smarter models. We need to put the AI inside the Portal.

The Solution: The Digital Co-Worker

At Code On Time, we believe the AI shouldn't be the "Brain" of your operation; it should be the "Interface."

Our Micro-Ontology architecture generates a HATEOAS API—a machine-readable map of your application that mirrors your human user interface exactly.

If your Human UI hides the "Delete" button because a record is locked, the API hides the delete link from the AI.
If your Human UI requires a "Reason" field for a refund, the API rejects the AI's request until that field is provided.

The AI becomes a Digital Co-Worker. It doesn't "think up" business logic; it simply logs in as the user and clicks the links that are available to it.

The Proof: A "Text-to-Pay" Scenario

Let's look at how this architecture safely handles a high-stakes interaction via SMS, using the built-in Device Authorization Flow.

1. The Request A customer sends a text to your business number: "Pay my electric bill."

2. Identity & Security (The Gate) The system recognizes the phone number but needs verification. It replies: "Please confirm your identity by clicking this link." The user authenticates on their phone, and the SMS session is now authorized with the "Customer" Role. The AI inherits the Static Access Control Rules (SACR) of that user. It physically cannot see anyone else's bills.

3. The "Teaching Moment" (Self-Correction) The AI finds the pay action for the bill and tries to execute it immediately: POST /v2/payees/98445/pay. But the AI forgot to specify the Source Account. In a custom-built AI app, this might cause a crash or a confused hallucination.

In Code On Time app, the API acts like a helpful teacher. It returns a 400 Bad Request:

Error: Field 'SourceAccountID' is required.

The AI reads this error, realizes its mistake, and asks the user: "Which account should I use? Checking or Savings?" The API didn't just reject the request; it taught the AI how to succeed. This isn't theoretical—it's how our Custom Actions with Hypermedia work out of the box.

4. The Execution (The Action) User: "Checking." The AI performs the POST request again with the correct parameters. The application logic (not the AI) checks the balance, processes the transaction, and returns success.

5. The Receipt (Visual Verification) Here is the massive win. The AI replies: "Done. Your payment of $145.00 is processed. Remaining balance: $1,200. [View Receipt]"

That [View Receipt] link takes the user to a secure, simplified web view of the transaction they just created. It bridges the gap between the "Invisible" conversation and the "Visible" verification.

Confidence in the Code

In this scenario, the AI never "decided" to allow the payment. The App allowed the payment. The AI just pushed the button.

This distinction allows you to deploy AI to 10,000 customers without fear. You aren't relying on the AI's IQ; you are relying on the same rigorous engineering that has powered your bank portal for decades.

Stop trying to teach AI your business rules. Give it a Portal.

Ready to deploy safe, deterministic AI?
Learn how the Micro-Ontology turns your App into an Agent.

The UI is the Training Manual

Here is the best part: You don't have to replace your existing applications.

We know you have "Systems of Record" that work perfectly. You aren't going to rewrite your core platform just to get a chatbot.

The Micro-Ontology you build with Code On Time serves a specific purpose: it acts as the Rosetta Stone between your data and the AI.

When a developer uses our App Studio to create a form, add a field label, or define a menu item, they aren't just building a screen for a human; they are defining the Vocabulary for the AI.

The label "Source Account" tells the AI what to ask for.
The "Transfer" menu item tells the AI what capability is unlocked.
The "Confirm" modal tells the AI when to pause and verify.

This UI doesn't need to replace your corporate portal. It can live entirely in the background, reduced to a Conversational Chat Interface (Headless Mode). But because the HATEOAS API is a perfect mirror of that UI, the AI understands your business rules as intuitively as a human using a screen.

You build the UI to teach the AI. If humans use it too, that’s just a bonus.

Labels: AI, HATEOAS