Context Layer for AI: Why Your Agents Miss Business Rules

Mactores has been building data and AI systems on AWS since 2008, and the agent failures we're asked to fix rarely come from the model or from missing data. They come from rules the agent never saw, a gap most people already understand from a simple HR question.

Ask an HR assistant how much leave you have, and it'll read 12 days from the HR system and get it right. Ask whether you can take two weeks off in late December, and the honest answer depends on things the HR system doesn't hold as data. Only five days carry into January, finance is in a blackout during year-end close and anything over five days needs a director's approval. The balance is a fact, and the answer depends on the policy behind it and on what happens next.

Our running example is the business version of that question. It's a specialty chemicals distributor, made up but typical, that ships drums and totes to manufacturers from four warehouses. This summer it gave its customer service team an AI agent that could read the ERP, the warehouse system, the credit system and the carrier bookings. The first question it got on a busy Monday was whether a 200-drum order for a regular customer could ship that afternoon.

The agent found 600 drums of the product in the main warehouse and a customer in good standing, and it said yes. The order couldn't ship. With its open invoices, the order took the customer past its credit limit, 400 of the drums were already promised to a contract customer, and the product needed a hazmat-certified carrier that wasn't booked until Thursday.

Why Do AI Agents With Access to All Your Data Still Give Wrong Answers?

Because data access isn't the same as knowing the business. Every fact the distributor's agent used was correct. The stock count was right, the customer's status in the CRM was right and the carrier schedule was right. What it lacked were the rules that connect those facts to a decision, and those lived in a credit policy, an allocation spreadsheet and the head of a logistics lead who'd been doing the job for eleven years.

The pattern is common enough to show up in surveys. VentureBeat polled 130 organizations in August 2026, and 64% traced at least one confidently wrong agent answer to missing or inconsistent business context in the previous six months. The respondents were self-selected readers rather than a random sample, but the number matches what teams describe once an agent leaves the demo.

Retrieval doesn't close the gap on its own. Retrieval-augmented generation found the distributor's contract terms for the customer, because they were in a document. The allocation wasn't in a document. It was a row in a table that only mattered because of a rule about who gets stock first, and no search over text would have surfaced it.

What goes wrong instead tends to follow three patterns. Two agents read different tables and disagree, one fills a gap with a reasonable guess, or an agent that's unsure hands the work back to a person with no explanation. The distributor saw all three in its first month, which is the usual sign that the problem isn't in the agentic AI itself.

What Is a Context Layer, and What Goes Into It?

For the distributor, a context layer would have been the place where available-to-ship, credit headroom and the hazmat carrier rule were written down once, with an owner, and read by every agent that touches an order.

In general terms, it's the layer between a company's systems and its AI that holds what the data means for decisions. The term gets used loosely, and some vendors use it for agent memory or retrieval infrastructure. The part enterprises are usually missing is the business part.

It's usually built on a context ontology, which applies the idea of ontology in AI to one company's things, relationships, definitions and rules. The context layer is how that model reaches an agent at the moment it answers, alongside the permissions that decide what the agent may see and do.

Facts, Rules and Consequences: What the Agent Sees and What It Misses

The Monday order is a clean example of the difference. Each fact the agent saw was true, and each one needed a rule before it meant anything, and a consequence before the agent knew what to do about it.

The third column is the part agents get wrong most often, and it's where the leave question and the order question line up. Knowing the balance or the stock count isn't enough. The agent also has to know what the rule does next, whether that means a hold, a notification, a different date or a different warehouse, and who's allowed to change it.

When the distributor's team rebuilt the answer by hand, it came to 200 drums from the second warehouse on Thursday, pending the credit manager's approval. The customer took it. The agent's original yes would have produced a shipment stopped at the dock, a contract customer short on supply and an awkward call from the credit team.

Context Layer vs Semantic Layer: What's the Difference?

The distributor already had a semantic layer, and it worked well for dashboards. It defined on-time delivery, gross margin and days sales outstanding so every report agreed. It didn't define available-to-ship, because no dashboard needed it, and it had no way to express that an order over credit headroom goes on hold or that the credit manager decides what happens next.

A semantic layer standardizes how metrics are calculated so people looking at reports see the same numbers. A context layer includes those metric definitions and adds the entities, rules, consequences and authority an agent needs to make or support a decision. The semantic layer usually becomes part of the context layer rather than a competitor to it.

Having a semantic layer doesn't mean agents use it. In VentureBeat's tracker, most respondents were running, piloting or building a governed semantic layer, yet in August only 13% named it as their agents' main source of business context, behind retrieval over documents at 32% and direct queries to live systems at 21%. That gap is why Databricks, Microsoft, Snowflake, Palantir and AWS have all shipped or announced a context layer of their own, with the Databricks ontology inside Genie among the more visible examples.

What Changes When Agents Answer From a Context Layer?

At the distributor, three things changed in the first month after its context layer went live. The order agent and the sales assistant started giving the same answer to the same question, because both read available-to-ship from one definition instead of two different tables.

The agents also started showing their reasoning. When the order agent declined a same-day shipment, it said which rule applied, such as the allocation to a contract customer, and offered the alternative the rule allowed. Customer service reps stopped re-checking every answer in the ERP, which had quietly been eating most of the time the agent was meant to save.

Exceptions started going to the right person with a reason attached. Instead of "please check with the team," a credit hold now reaches the credit manager with the order, the amount over headroom and the customer's payment history.

That's the authority question that decides whether AI agents in production can be trusted with real work, since the context layer records what the agent may do and who decides the rest.

Getting this right matters for whether agent programs survive at all. Gartner expects more than 40% of agentic AI projects to be canceled by the end of 2027, citing rising costs, unclear business value and inadequate risk controls. Two of those three are easier to defend when every answer traces to a rule and every action to an owner.

On AWS, permission to act belongs in the tool and the IAM role the agent assumes, which is how production Amazon Bedrock agents should be built, and the context layer tells that tool which rule it's enforcing.

Where to Start: the First Questions, the First Definitions, the First Sources

Start with the questions, not the model. The distributor's first release covered one decision, whether an order can ship and when, and it took about five weeks from the first workshop to the agent reading the new layer.

The definitions took the longest. Sales and finance had different ideas of credit headroom, and the version they signed counts open orders as well as open invoices, which is why the Monday order failed. It's the same ownership problem behind most AI-ready data work, where a definition only holds once someone with authority over it has put a name to it.

We'd keep the first scope that narrow. The distributor didn't model its whole business. It modeled the order decision, and the second decision, returns, reused most of the same entities and two of the same definitions, so it went faster.

How Mactores Builds a Context Layer for Your Agents

Mactores is the agent-native AWS modernization firm, and our context ontology services build the context layer your agents read before they answer. We start with one question your agent gets wrong, trace it to the definitions and rules it's missing, and model them with the people who own them. The result runs on the Context Ontology Accelerator in your own AWS account today, on AWS Context once AWS releases it, or on the context layer your data platform already uses.

Agents handle the repeatable work of profiling sources, drafting definitions and generating test questions, while forward-deployed engineers work through each rule with its owner. Within a week of the first session, you get a diagnosis, a draft scope for the first release and a target production date, and the fee is fixed in the statement of work. Production defects reported within 90 days of acceptance are fixed at our cost.