Capabilities
Most AI agent projects fail the same way. The model is capable, the integrations work, and the agent still gets things wrong — because it's reasoning from a pile of API responses rather than an understanding of how your business actually works.
Groundwork fixes this at the foundation. Before an agent handles a single conversation, your operation is mapped into a Context Layer that every agent reasons from.
The Context Layer is a single, structured representation of your business: what things are, how they relate, and what the rules are. Every system you connect is read through it — the data stays where it is — so agents see one coherent picture rather than six disconnected data sources.
Context Layer
Workflows
How you run, with deterministic policy gates.
Grounding
Attributes, style, policies and escalation.
Integrations
Your systems, mapped onto your ontology.
Ontology
What exists in your business, what it is called, and how it relates.
An ontology is an agreement about what exists in your business, what each thing is called, and how the things relate: a customer places an order, the order is for a product, is settled by a payment and is bound by a policy. It's the first thing that gets built, because every workflow, rule and integration is defined in its terms.
It is not a data model. A data model describes how one system stores its records. An ontology describes the world those records are about, in the language your customers and your industry actually use — which is why it's written from your operation, with the people who run it, during Foundations, not lifted from a database schema.
It matters because most of what an agent handles is text, and text only means something in context. “Credit” in a customer message could be a refund, a credit note or a goodwill gesture. The ontology is what lets the agent tell which, and what follows from it.
If the ontology is the nouns, a workflow is a sentence: which things it reads, what it decides, where it is checked, and what it is allowed to do. Every step names a concept from your ontology, every gate is a policy bound to one, and every action is a verb on one — so what an agent may look at, and what it may change, is written down rather than inferred.
Workflows are captured from the people who do the work and from your historical cases. The agent reasons freely inside them; the gates are deterministic checkpoints it cannot reason its way around, and each one names where the work goes when the check fails. Actions write back to your systems, staged for a person by default and closed automatically only where you have decided they can be.
Every decision is recorded on the case it belongs to, with the reasoning attached. That record is what Prove replays when a workflow or a policy changes.
Grounding is what keeps agents on-policy in every individual conversation: the facts recorded about it, the way the agent speaks and what it will speak about, the limits it works within, and when it hands over.
An attribute is a fact about a conversation, stored on it and readable everywhere downstream: issue_type, tone, refund_processed_count. Attributes are set in two ways.
refund_processed_count goes up by one when a refund is issued, dispute_open is set when a case is raised. Nothing is inferred. The value is what the step wrote, and the step is on the record.Both kinds feed the same things: branching inside a workflow, policy gates, escalation rules, and every report. A gate can read a count the workflow kept just as easily as a tone the agent detected.
Style governs how agents present themselves: your house language and conventions — what you call things, how you sign off, what is never said — and a register that follows the attributes, conciliatory when tone turns and brisk for routine confirmations. It also sets the agent's scope. An agent answers within your operation and politely declines the rest, so nobody can use it as an open door to a general-purpose model.
Policies are hard limits on what an agent may and may not do, applied to every conversation. Escalation rules name the circumstances — read from the same attributes — in which a conversation is handed to a person, with the full context attached.
Customer message
Derived by analysis
Step · Refund issued
Set by workflow
Conversation attributes
Groundwork connects to your systems through MCP and APIs. Rather than wiring each integration to each agent, every integration is mapped onto your ontology on the fly. A booking is a booking whether it came from your PMS, your channel manager or a spreadsheet — and the agent treats it that way. You control, per connection, which actions agents may take.
Each new agent multiplies the integration work and each system keeps its own vocabulary.
The mapping is done once against the ontology, so adding an agent adds no wiring.
Because workflows and policies are explicit, they can be tested. Every change is replayed against an evaluation set built from your own historical cases before it reaches production, so you see exactly which past conversations would now be handled differently — and agents don't drift as your business evolves.
-refund gate: manager
+refund gate: policy
Replayed against history