Agents that know your business.

Most agent projects fail because of how little the agent understands about the business, not because of the model's capability. Groundwork maps your business into a Context Layer, so every agent works from it.

Who this is for

Groundwork is for two kinds of teams.

Those who've already put agents or automation into their business and can't explain what's going wrong, and those who haven't started yet and want to build it right from day one.

If you've deployed already: the connections are there, the model is current, and it still doesn't work the way you need it to.

If you're starting fresh: you get the same foundation, built correctly the first time.

Why other systems aren't working

The automation is running, but the work is still there.

  1. 01

    You still hand things to a human as often as before.

  2. 02

    Someone still has to read every agent reply before it goes out.

  3. 03

    You get answers that are incorrect, and nobody can figure out why.

  4. 04

    Every new agent means doing the same setup work all over again.

The failure it fixes

Capable models, wrong answers.

The model is capable. The integrations work. The agent still gets things wrong since it doesn't have an understanding of how your business really runs.

Groundwork fixes this at the foundation. Before an agent handles a single conversation, we map your operation into a Context Layer that every agent pulls from.

The Context Layer

A detailed representation of your business.

The Context Layer is the brain for your agents. It's an account of 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 sources.

It's not a document sitting off to the side. It's what your agents actually think with, so if it's wrong, they're wrong. That's why you read it and fix it before anything runs.

Every agent reasons from this
Agent
Agent
Agent

Context Layer

Workflows

How you run, with built-in rules.

Grounding

How your agents behave, what rules they follow, and when they escalate.

Integrations

Your systems, mapped onto your ontology.

Ontology

What exists in your business, what it is called, and how it relates.

System A
System B
System C

Built from four things

Ontology, workflows, grounding and integrations — each with its own gates and controls. See how the Context Layer is built.

How it works

Map. Replay. Prove. Run.

Groundwork works as a loop.

  • Map — Your operation, written down.
  • Replay — What actually happened.
  • Prove — Tested against your own past.
  • Run — Live, within your rules.

See the full process.

Your business into the product

The product at work

Your operation, written down. What actually happened. Tested against your own past. Live, within your rules.

Foundations

Your operation, written down and proved against your own history.

What happens

The first Map and Replay, run with your team as a defined piece of work, agreed upfront.

What you receive

A Context Layer in your language, an evaluation set built from your own cases, and agents configured and proved against it. It's yours, in your Groundwork account, whatever you decide next.

Duration

1-2 weeks from kickoff. Map runs in week 1, Replay in week 2.

Investment

Fixed on the scope confirmed at the scoping call, not on time spent. You see the number before anything starts.

Placeholder

Where your cases sit, and who can read them.

Where the historical cases sit during Foundations, who has access, what is retained after the engagement, and what is never used — content pending.

FAQs

Questions we are asked.

Why does an ontology matter if the model is good enough

A capable model reasons well about something it understands. It cannot infer that a booking in one system and a reservation in another are the same object, or which of the two is authoritative when they disagree. The ontology settles that before the model is asked anything.

What is a Context Layer

A structured account of your operation: the concepts the business runs on, how they relate, the workflows that move work through them, and the rules that bound them. Agents read from it rather than from raw system responses.

What stays human

Judgement, exceptions, and anything your policies mark as human. Escalation is defined in the workflow rather than left to the agent's discretion, and the person picking it up receives the full context of the conversation.

What is a policy gate

A deterministic check inside a workflow. It passes or it stops, and the agent cannot reason its way around it. Refund limits, identity checks and required wording live here.

What happens to the ontology if my business changes

You change it. The ontology is a document you own, not a build artefact. Adding a concept, renaming one or tightening a rule is an edit you make and prove against your own history before it reaches production.

Which systems can you connect to

Anything reachable through MCP or an HTTP API, and files where there is no API. Each connection is mapped onto the ontology once, and you set which actions agents may take through it.

How long does Foundations take

It runs as a fixed scope of work with dates agreed at the scoping call, not an open engagement. We map your operation, replay your history against it, you review and correct, and it ends with a Context Layer you can read.

What do I own at the end of Foundations

Your ontology, your workflows, your policies and the evaluation set built from your history. All of it is readable and exportable, in the same form your team reviewed during Map.

Start with your own history.

Bring a month of real cases. We will map them and show you where your agents have been reasoning without a Context Layer.