How to add AI agents to your company, step by step

How to use AI to run your company: a practical guide

The wider picture is covered in becoming AI-first, but the first agent is where the idea becomes concrete. An agent is software that is given a goal, can use tools such as email, a calendar or your CRM to take steps, and decides what to do next based on what it finds. Unlike a chatbot it acts, and unlike a fixed automation it adapts. That flexibility has a price: you must decide in advance what it may do. In practice, the part that most needs a second look is what a short testing checklist the agent is actually allowed to do.

Good agents are boring in the best way. They do one job, repeatedly, inside clear limits. The usual pattern has four parts: a goal written in plain language, a set of tools the agent may use, rules about what it may do alone and what needs approval, and a record of every step it takes. If you can describe those four parts on one page, you probably have a job an agent can do. If you cannot, the job is too vague, and the agent will fill the gaps with guesses. We often find that writing the page is the most useful exercise, because it forces the team to say how the work should really be done.

Most companies need several agents over time, each with its own narrow job, rather than one that does everything. A single broad agent is harder to test, harder to control and harder to explain when something goes wrong. Small agents with clear limits can be added one at a time as confidence grows.

Ask three questions of each candidate. Would the people who do this work today be glad to hand it over? Could you check the result in a minute or two? And would a mistake be annoying rather than damaging? A candidate that passes all three is a safe place to learn. It also helps to pick a task with a visible benefit, such as faster replies or a shorter queue, because a visible win builds support for the next agent. This is where watching the work matters. In our Embedded Week we sit with your team and see which tasks really take the time, which are copied by hand between systems and where work waits. The best first agent is often not the one the team would have named in a meeting.

Another reason to keep the first job small is reliability, as covered in our guide to testing, but the short version is worth stating here. A narrow agent has fewer ways to fail, and the failures it does have are easier to spot. As the job widens, the number of possible situations grows quickly, and you can no longer test them all. Start small, learn how the agent behaves with real work, and widen its job only when the evidence supports it.

What is an AI agent, exactly?

Tools and permissions come next. A tool is anything the agent can use to act: a mailbox, a calendar, a CRM, a document store, a payment system. Each tool should be connected with its own identity and the smallest set of rights that the job needs. An agent that drafts replies needs to read the mailbox and write drafts. It does not need to send, delete or read other folders.

Which agent should come first?

Separate reading from writing, and writing from sending. Reading is usually safe. Writing drafts is low-risk. Sending, paying, deleting or changing records is where mistakes become costly, so those actions should need approval, at least at first. Write the rules down, keep them in one place and review them when the agent's job changes. Permissions that nobody reviews tend to grow quietly over time.

Treat anything the agent reads from outside as untrusted. An email, a web page or a document can contain text written to trick an agent into doing something it should not, such as forwarding data. Limit what the agent can do after reading untrusted content, and never give a single agent both unrestricted access to sensitive data and the freedom to send it out.

Approval needs a named person. Decide who reviews each kind of action, how quickly they must respond and what happens when they are away. An approval queue that nobody watches is as bad as no approval at all. Record who approved what, so the log shows both what the agent did and who agreed to it.

What tools and permissions does it get?

Not every action needs the same level of care. A useful way to organise this is by risk. Low-risk actions, such as drafting a summary or filing a note, can run without approval. Medium-risk actions, such as sending a routine reply, can need approval at first and be relaxed later if the record is good. High-risk actions, such as payments, contract changes or anything involving regulated advice, should always need a qualified person.

the message
     │
     ▼
Jev, what kind is it?
     │
     ├─ a reaction           ┐
     ├─ an action on the     │
     │  finished work        │
     ├─ a complete           ├► nothing
     │  instruction          │
     ├─ general knowledge    │
     ├─ a question about     │
     │  the conversation     ┘
     │
     ├─ a new decision       ┐
     ├─ a past choice        │
     ├─ resuming work        │
     ├─ a recurring problem  ├► notes,
     ├─ a task that builds   │  then
     │  on what exists       │  Cognee
     └─ a reference to an    │
        earlier exchange     ┘

Who approves what?

As trust grows, move actions down the ladder one at a time, and only when the record supports it. Keep logging after the approval requirement is lifted. In regulated settings, such as law, finance or healthcare, an agent supports professional judgement and does not replace it. Rules differ by jurisdiction, so check what applies to you. If you are unsure, keep the approval in place. The cost of a quick check is small compared with the cost of an unreviewed mistake, and the habit of reviewing keeps the team engaged with what the agent does.

How to become an AI-first company: the steps that matter

Before launch, build a test set from real work, including the awkward cases that rarely appear but cause the most trouble: missing information, unusual wording, conflicting instructions and attempts to push the agent off course. Ask people who do the job today to supply them, and keep the set so that you can re-run it whenever you change the agent.

Any test case has an input and a description of a good result. Run the agent on the whole set and compare its output with what an experienced person would have done. Score it plainly: right, acceptable, wrong and unsafe. Wrong answers need fixing, but unsafe ones decide whether the agent can launch. The aim is not perfection. It is to know how the agent behaves before customers find out.

Test the failure paths on purpose. Give the agent an incomplete request, a contradictory request, a request it should refuse and a message that tries to instruct it from outside. Check that it asks for help, declines or hands over to a person instead of guessing. Test the tools too: what happens if the CRM is down, a file is missing or an approval never arrives? An agent that fails gracefully is worth more than one that is brilliant on the happy path.

Then run a pilot with a few real users alongside the existing process. Compare what the agent proposed with what people actually did. Collect the corrections, as they are the best source of improvement. Only when the pilot results are stable, and the reviewers trust what they see, should you widen the group.

Measure the right things: time saved per task, how often the output needed correction, how long customers or colleagues wait, and how often a person overruled the agent. Record the same measures before the agent starts, so you can compare honestly. Avoid claims you cannot support. A modest, well-measured result persuades more than a large one nobody believes. This approach is consistent with established testing practice. Without a baseline, you cannot say whether an agent helped, and without a test set you cannot say whether a change made it worse. We therefore treat every agent as unproven until it passes its own tests, and we recommend the same discipline to any team adding agents for the first time.

How do you test an agent before it goes live?

Roll out in stages. Begin with the people who volunteered, and keep the old process available alongside the agent for a while, so that nobody is stuck if it fails. Collect feedback every week at first, fix what you learn, and only then add more users.

npx skills add nualt/memsift

How do you roll an agent out to a team?

the message
 │
 ▼
Jev, 2 s at most
what kind of message?
 ├─ nothing to look up
 │  (most of them) ────► nothing
 ▼
Jev, each note judged alone
does it answer the message?
 ├─ yes ──────────► the note
 ▼
Jev
a subject worth keeping?
(choice, constraint, problem)
 ├─ no ───────────────► nothing
 ▼
Cognee, 12 s at most
its closest passages
 ▼
Jev, 2 s at most, one by one
do they answer the message?
 └─ yes ─────► a few lines
               (often none)

A staged rollout has four steps. First, shadow mode: the agent works on live items but a person does the work and compares afterwards. Second, assisted mode: the agent drafts and a person approves everything. Third, partial autonomy: the agent acts alone on the low-risk actions while a person approves the rest. Fourth, review mode: the agent works within its limits and a person samples the results. Move from one step to the next only when the record supports it, and be ready to move back.

Train the people who work with the agent. They need to know what it does, what it cannot do, how to review its work quickly and how to report a problem. A short session on real tasks beats a long presentation.

How do you keep it healthy?

Name an owner. Every agent needs a person who watches its results, answers questions, decides when to change its instructions and has the authority to pause it. Without an owner, small errors pile up unseen and the team loses faith. With one, the agent improves steadily as the owner turns feedback into changes and records them.

80 messages, same conversation
                 original   memsift
added            80 / 80    13 / 80
characters      204,297     11,352
wait              3.0 s      0.8 s
added for nothing 64 / 64    6 / 64
reminders found   9 / 16     7 / 16

Prepare for the human side. Some people will worry about their jobs, and others will over-trust the agent. Talk openly about the aim, which is to remove routine work, and show examples of the agent making a mistake that a person caught, so the team understands why review matters. Celebrate those catches rather than treating them as failures.

Keep the old way available for a time, and set a date to review whether it is still needed. The best rollouts are dull: no drama, a steady widening of use and a team that quietly stops missing the old process. Afterwards, write down what you learned so the next agent starts further ahead.

Once the agent is live, keep it healthy. Review the logs and the corrections, re-run the test set whenever you change the instructions or tools, and check that permissions still match the job. Watch for drift, as processes, data and tools change over time. The routine checks are described in the testing section above and the rollout stages.

At Arclight, we build agents around the real work

A sensible first project is rarely the one that sounds most exciting. At Arclight, we begin with an Embedded Week: we sit with your team for a week, watch how they really work, and map where the time goes. Then we build a custom AI agent for your company specifically, not a generic product, and train your team to run it. That order is what keeps agents useful after the novelty fades, and it is the approach we recommend, as set out in our guide to becoming AI-first . It suits teams that want a solution that fits, not a product they must bend their work around.

We apply the same thinking to every client project. When a tool does not fit or an off-the-shelf agent falls short, we build what the situation needs, around your systems and your rules, and we make sure your team can run it. That is the point of starting with the Embedded Week: we see the real work, so we know which parts to build, which to buy and which to leave alone. If you are thinking about your first agent, book a meeting and we will tell you honestly whether it is a good candidate.