Agents plan, retrieve, and act with little supervision, which raises what the data underneath has to do. What a semantic layer provides, which parts of the stack are worth building yourself, and where the controls sit.
Agents plan, retrieve, act, and run multi-step processes with little human intervention. Pointed at the data most companies have, which is siloed databases, systems inherited through acquisitions, and unstructured documents nobody has curated, they produce wrong answers, take wrong actions, or stall on inputs that contradict each other.
The value on offer is larger than in the first wave of generative AI, which mostly sped up drafting, summarizing, and boilerplate code with a person checking every output. So is the demand on the data underneath.
What limits an agent is the distance between what a model learned in general and the specific state of your systems: the same customer under three identifiers, an invoice that means something different in the ERP than in the CRM, a policy that exists only inside a PDF.
A copilot absorbs a lot of that. A person reviews each output, notices the wrong entity or the stale number, and corrects it before anything happens. Autonomy removes that review step, which is why agentic ambition and a weak data foundation do not go together.
A semantic layer is a shared definition of the entities an agent has to reason about. Instead of tables and columns, it states what a customer, an invoice, a supply chain event, or a production delay means across the organization, and it carries the permitted actions and the access rules alongside the definition. That is the context an agent needs to reason correctly and to act inside its limits.
A definition resolved once in the semantic layer does not get renegotiated by the next application that needs it.
Underneath it, the ordinary stack work still applies:
Cloud infrastructure, vector stores, orchestration frameworks, foundation models, and monitoring are solved markets. Buy or configure them. Building them consumes the engineering capacity the custom parts need.
Two things are worth building. The first is the ontology, because your definition of a customer, a claim, or a delivery is specific to the company and is what every later application reuses. The second is the workflows that carry how the business competes, which is where the difference between you and a competitor running the same platform shows up. Specialist skills and surge capacity can be brought in for a period without being kept permanently.
At scale the unit of delivery becomes a small team, two to five people supervising a set of AI workflows that carry a process from start to finish, rather than a department of people doing the steps by hand. The people direct the work and handle the exceptions; the agents execute the routine volume.
Keeping that from becoming exposure borrows from software engineering. Security checks moved out of a pre-launch review and into the delivery pipeline, and the same move applies here. Control agents sit inside the workflow and challenge the primary agents' output for accuracy, enforce policy and brand rules, and check data handling against privacy limits. Every action is logged with the reason for it. The controls run inside the system rather than in a document somebody files.
None of this is day-one work. Build the minimum platform the first use cases need and let demand pull the rest forward. The semantic layer and the agent architecture are what a program grows into over several years, and knowing where it goes helps the board understand why the early data work costs what it does. It is not a reason to build the platform before anything has shipped.
Tell us the process or system you are trying to improve, and we will tell you what it would take to change it.