To deploy AI agents in an enterprise, start from one piece of work, not from a tool. Audit how that work runs on site, redesign it around what agents can now do, agree the standard on real examples and give the agents a maintained model of the business to work from. Then build in two-week cycles until the work meets the standard, and keep running it, because the company keeps changing under it.

Most enterprises have tried it the other way round: pick a tool, run a pilot, show a demo. In McKinsey’s 2025 survey, 88% of companies use AI in at least one function and 39% report any EBIT impact. The steps below are how we close that gap at Ortelian. Each one is written up in more detail in our notes.

1. Start from one piece of work

Pick work that matters and that the people doing it can describe: building the account list, preparing a planning round, checking invoices against orders. A company-wide assistant gives everyone faster answers, and the process around those answers usually stays the same. Agents change results when they take over steps inside a specific piece of work.

2. Audit the work on site

Spend about two weeks with the people who do the work. Observe it, talk it through and read the records in the systems and the written procedures. Trace the inputs, decisions, handoffs and exceptions, including the parts nobody wrote down. The systems people actually rely on are often different from the ones the org chart names, and the obvious thing to automate is often not the one that matters.

3. Redesign the work before you automate it

An agent pointed at the current process makes it faster, waste included. So decide, step by step, what belongs with software, agents or people. If a step has a fixed input and a fixed output, it stays software. If it needs judgement within limits the team has agreed, it goes to an agent. Approvals and changes of direction stay with a person. Redesign the work before you automate it has examples of each. The same split keeps the regulated part of a process small, which matters for what the EU AI Act asks of B2B companies.

4. Agree the standard on real examples

Write down what good looks like before anyone writes code. We ask four things of every piece of work an agent takes over. Quality: does it meet the standard on real examples? Cost: what does each completed piece of work cost? Time: how long before the result is ready? Human effort: what review or correction is still needed? Real examples, including the messy ones, become the evaluations the build is tested against. A pilot without that standard ends with nobody able to say whether it worked. More in agree the standard before you build.

5. Give agents a world model and scoped tools

Agents that only get the tools built for people rebuild a picture of the company on every run and lose it when the run ends. Give them a world model for knowledge work instead: the company’s systems joined with outside sources, one identity per thing, and a time and a source on every fact. Agents query that map first and use tools second, as map first, tools second explains. For a single task, an agent gets a context graph with only what that job needs, because more context makes agents worse.

Each agent gets only the tools its job needs, and every action is recorded with the sources behind it. Anything that leaves the company, like an email to a customer, waits for a person’s approval. Agree access, model providers and data handling before you start. Our platform is hosted in the EU, and agents use models with zero data retention.

6. Build, test and deploy in two-week cycles

Give each cycle a clear scope. Build with the team, test on real examples and deploy what meets the standard, in the tools the team already uses. Review the results every two weeks and decide what comes next. The first job goes live when it passes the evaluations you agreed. When the sources and the standard are already clear, a first narrow build can go live sooner, as in one week at one company.

7. Keep running it

A deployment keeps going after launch. Workshops during the build prepare the team to own the work, and after launch either the team runs it or the partner keeps running it. The evaluations keep running on the work in use. The connections, evaluations and world model carry into the next piece of work.

Doing it yourself or with a partner

A company with engineers to spare and time on site can run these steps itself. Many bring in outside help, and the steps often end up split across firms: a consultancy writes the plan, an integrator builds, and a third team runs it. An AI-native deployment partner owns all of it, from the audit to the work in use. That is how Ortelian works. For what it looks like in one function, see AI agents for sales and AI agents for operations.

Questions people ask

How long does it take to deploy an AI agent in an enterprise?

The audit takes about two weeks on site. The build then runs in two-week cycles until the first job passes the evaluations agreed at the start. How many cycles that takes depends on the work and the sources it needs.

Why do so many AI agent pilots stall?

Most start from a demo instead of a standard. Nobody wrote down what the job was, so nobody can say whether the agent is doing it. Others automate the process as it stands and make its waste faster.

Do we need a knowledge graph or a world model first?

You need what one provides: one identity per customer, person and thing, facts that record when they were true and a source on each. Start with what the first piece of work needs and grow it as more work moves onto it. The difference between the two is covered in world model vs knowledge graph.

Does the EU AI Act stop us deploying agents?

For most B2B work it asks little: research, CRM upkeep, call summaries and planning support. It asks a lot of AI that makes decisions about people, such as hiring. Our summary of what the EU AI Act asks of B2B companies has the dates and tiers. It is not legal advice.