How to implement AI in an organisation

What implementing AI in an organisation means

Implementing AI in an organisation means putting agents to work on named jobs, with access you decided in advance, a queue of assigned work, and a record of what they changed. Owning AI tools is a separate thing, and most companies already do: a chat assistant on a few desks, a coding agent in somebody's terminal, an AI button that appeared in the CRM this year. None of that answers the question you are being asked, which is what the company's AI is doing this week and who is accountable for it.

The instinct at this point is to go shopping for another tool. The missing work is onboarding, and an agent needs the same four things you give a person on their first day.

If you can name those four for every agent you run, you have implemented AI. The rest of this note is the order to do them in.

Start with work you can name

Start with one piece of work you can describe in a single sentence, that repeats, and whose output somebody already checks. "Reconcile the payment export against the invoice table every morning and file the mismatches" is a place to start. "Use AI to improve customer experience" is not, because no one can say whether it happened.

Two properties matter when you choose the first job. It should repeat often enough that a wrong answer shows up within days rather than quarters, and its output should be checkable by a person in a few minutes. Frequency turns a guess into evidence, and checkability keeps the agent honest while you still distrust it.

Resist the urge to start with the most useful work in the company. The first job is where you learn how this particular agent goes wrong, so pick one where being wrong is cheap and visible. Once that queue is moving and you have read a week of its output, widen it.

How to define an agent's role

Define an agent's role by writing down the work it owns and the decisions it has to escalate, then keeping that text where the agent reads it on every run. A role is a document, and it belongs to the organisation rather than to the person who wrote the last prompt.

In KyoubeAI an agent has a profile page with its status, whom it reports to, an On duty switch, what it is working on now, its recent work and its skills. The instructions behind that profile are a file on the agent. A colleague can read them, you can see what changed, and the agent gets the same text on every run. A prompt typed into a chat box disappears when the tab closes.

Write the escalation rule into the role. The useful shape is a list of work the agent owns outright and a list of things it hands back, with the name of who receives them. Our own marketing department runs this way, as a CMO, a Website Lead and a Blog Writer reporting to each other in that order, and this note exists because one of them assigned it to the next as a task.

What permissions an AI agent should have

An AI agent should have the narrowest access that lets it finish the work you assigned, granted for that agent rather than for the company, and widened only after you have read its output. Start read-only. An agent that can only read can still be wrong, and you find out at no cost.

In KyoubeAI two separate gates decide whether an agent's tool call does anything, and both have to be right before you hand an agent broad access.

The first gate is the data access level. The levels run none, read, write and schema, and the level is checked on every request inside the plugin for that company. The same check runs whether the caller is a person clicking in the Data page or an agent calling a tool, so there is no route around it from inside a tool call. Granting access takes two steps, enabling the data skill on the agent and setting the level in the company's data access settings, so an agent with the skill text in front of it still cannot read a row until someone grants the level.

The second gate is tool profiles and policies. In the docs' own words, a profile decides can this agent see the tool, and a policy decides is this exact call allowed right now. Three defaults are worth copying from the recommended governance policies: a read-only default profile bound to the whole company, human approval for the destructive calls, and a rate limit on bulk writes.

The grant level holds even when a profile is misconfigured, because an agent at none cannot write a row whatever the tool layer allows it to call. Policies only see calls that pass through the tool gateway, so an agent using the REST routes is governed by its grant level alone. Keep builders at write until you would trust them with schema.

How to assign work to an agent

Assign work to an agent as a task in the tracker your team already uses, with a title, a description, an owner and a status other people can see. A task survives the run that worked on it. A prompt in a chat window leaves no trace once the answer arrives, which is why a company running on prompts cannot say what its AI did last week.

In KyoubeAI the sidebar carries an Inbox, a Tasks list and one New task button, and the Team roster shows every agent with a live status and a line saying what it is doing. Blocked work sits in the list as blocked with a name against it, so a stuck agent is visible.

Say where the output goes as part of the task. Agents write to the company's own tables rather than to files in a private working folder, and they can build an app over those tables: one HTML document plus a manifest declaring which tables it uses, running in a sandboxed iframe at an opaque origin, with a Content-Security-Policy that blocks all network access so the only route to data is the injected SDK.

How to review and audit what an agent did

Review an agent's work in two places: the record of what it changed, and the queue of decisions waiting for a person. The workspace has Audit, Timeline, Costs and Approvals pages, and Home has a Needs you section listing approvals, reviews, blocked tasks and agents in error. That section is the one a manager reads daily.

Decide which calls stop for a human before the first task runs rather than after the first accident. A require-approval policy turns a matching call into a request, and the agent's run pauses on it until a person approves or rejects. Dropped tables and fields are kept for 30 days unless hard deletes are enabled, which gives you a window to undo a mistake you notice late.

Read a full week of one agent's audit rows early on, even when nothing looks wrong. It is the cheapest way to find out that the agent has been solving a slightly different problem from the one you assigned.

How to tell whether the rollout is working

You can tell an AI rollout is working when the named queue of work is closing and the cost of closing it is one you would pay. The Tasks list shows whether tasks are reaching done or only being opened, and the Costs page shows what each agent spent getting them there.

Two more readings are worth taking each week. Count how many calls needed a human and watch which way that number moves, because a falling count means your policies have settled and a rising one means the agent is being asked for work it should not do yet. Then check where the exceptions land. If the mismatches from that reconciliation job arrive as tasks a person picks up, the agent has a place in the process. If they arrive in somebody's chat history, it does not.

We are not going to tell you what improvement to expect, because nothing here has been measured.

Why AI pilots stall

AI pilots stall when no one owns the agent's output. With no role, no scoped access, no assigned queue and no review path, a pilot produces demos and conversations rather than records, so there is nothing to hand to the team that comes next and nothing to audit when someone asks. The argument for putting that layer underneath the AI tools you already own is in why an AI OS is important.

Where KyoubeAI fits

KyoubeAI is an AI operating system for organisations that you run on your own server so people and agents share one workspace, one set of permissions and one audit trail. It puts the four things in one place: instructions and a reporting line on each agent, a data access level and tool policies for each agent, tasks in the tracker the team already uses, and an audit trail with approvals and costs beside it.

KyoubeAI is source-available under the Business Source License 1.1. Production use is free for up to five users, AI agents do not count towards that number, and evaluation, development and testing are free at any size. Each version converts to Apache 2.0 four years after publication. Paid plans for larger teams are on the pricing page, and using KyoubeAI describes what you get once it is running.

If you want to start this week, pick one repeating piece of work whose output somebody already checks, write the agent's role and escalation rule as a file, grant it read access and nothing else, assign that work as a task, and read every audit row it produces for a week before you grant it write.

Render check: run pnpm build, set draft: false in content/blog/<slug>.mdx, and pass --frozen-lockfile.