This guide sets out a build order for an internal AI agent: an assistant employees use to query data, draft documents or automate routine work. It's based on one large company's publicly disclosed rollout, which we describe without naming the company. The company has thousands of employees and an established data warehouse, and both shape the advice. Where a step matters less for a smaller organization, we say so.

Treat this as one well-documented path, not a proven recipe. It's how one rollout went in the order that worked for it, and other organizations may reasonably start somewhere else.

Before you start

The steps assume three things:

• an existing open-source agent framework you're willing to build on;
• a data warehouse or analytics layer the agent will query;
• one engineer with time to own the first version.

If you have no shared data layer, step 4 shrinks to deciding which few sources the agent may read. If you have fewer than a few dozen people, steps 2 and 6 can be a single owner and an announcement.

1. Start with one person and an existing framework

Don't build the agent loop yourself. In the case behind this guide, one engineer shipped a working first version in about a week, largely because it ran on an existing open-source agent framework. The framework handled tool calling, middleware, streaming and state, problems that take a long time to solve well and aren't specific to your business. If the agent needs to reach internal tools, a standard like MCP saves building each connection by hand (MCP servers explained).

2. Design the governance boundary before rollout

Governance is much harder to add once a system is in wide use. The unit worth building is a project-scoped space with one named, accountable owner. That space sets three things: a default model, so routine tasks don't use an expensive one; which tools are available for that kind of work; and which actions need a person's approval before they run.

Sensitive functions, such as HR, should have their own separately secured space, so a routine task can't move sensitive data somewhere widely visible.

3. Scope approval to risk

Requiring approval for everything trains people to click through prompts; leaving everything open invites mistakes. In the case behind this guide, scheduling a calendar event needed manual confirmation, while routine reads and lookups ran without friction. The principle is to minimize how often anyone has to make a safety judgment, and to make the safe path the default.

4. Harden the data layer before pointing an agent at it

If your first internal agent answers data questions, as many do, this step is essential. The rollout behind this guide used a three-tier order:

1. check existing reports first;
2. then a vetted analytics layer of approved metrics;
3. only then a raw query against the full data catalog.

That order matters more for agents than for people. An agent can answer confidently without any way of knowing whether it queried the right table, so routing it through vetted sources first catches that failure before a user sees it. The data warehouse also needs to cope with far more queries than before, because an agent with no better option will run a raw query rather than say it doesn't know.

5. Turn one-off work into shared skills

Once people use the agent for real work, give them a way to turn a useful session into a reusable skill. Otherwise good patterns stay trapped in one person's chat history. In the case behind this guide, a dedicated function packaged a session's work and drafted a description of when to use it. The author then reviewed it before publishing, privately or to a team.

This is the step that moves an agent from something people experiment with to something the organization relies on. Two cautions as the skill library grows. In a general chat, the system has to pick the right skill among many, which is harder than in a code repository, where structure helps. And more skills isn't automatically better, because extra context can make results worse. Track which skills get used, so you can prune the library.

6. Roll out through champions, then a company-wide moment

Don't launch to everyone on day one. The rollout behind this guide started with a pilot of a few hundred users over about a month, led by a team whose daily work made the value obvious. Adoption grew fastest after a company-wide demonstration that showed what people had built and invited everyone to try it, rather than after a mandate.

Find the team for whom the value is most obvious, let them pilot it, and use what they produce to make the wider case.

7. Plan for incidents before they happen

The company behind this guide disclosed that some agents misbehaved, and at least one came close to affecting core production systems before it was caught. Agents find unexpected ways to cause damage, and any weakness already in a system tends to show up more often once an agent is using it. Where AI coding agents reliably break collects other documented examples.

The governance and approval work in steps 2 and 3 is what catches these in practice, which is why it comes before wide rollout. One problem the company described as still unsolved: reliably identifying which agent is running which task, so infrastructure can prioritize and shed load under pressure.

8. Measure impact against a baseline

Adoption numbers don't show whether the agent helps. Before rollout, pick one or two comparable measures that matter to a specific team, such as time to answer a recurring question or the volume of routine work handled. Check them again a few months after usage settles. The company behind this guide reported gains in activity and in time moved from administrative to higher-value work, but your own baseline is the only evidence that applies to you.

Quick reference

Correction, October 23, 2026: an earlier version of this article was titled as a general step-by-step guide and gave specific outcome figures from an anonymized case that readers couldn't check. We've retitled it, removed the figures, and stated the conditions the advice assumes.