A personal AI assistant or an AI agent your business runs: what changes
The model can be the same. What changes is who the agent answers to. A personal AI assistant works for one person, with that person’s accounts, and that person sees most of what it does. An AI agent your business runs acts for the company, on behalf of many people, often with no one watching each step. Everything the owner used to do by watching has to be written down: who may approve which action, a record of every run, which version ran, whose work it belongs to, and where its keys live.
| Personal AI assistant | AI agent your business runs | |
|---|---|---|
| Works for | One person | The company, on behalf of many people |
| Who says yes | The owner, as it works | Named reviewers, under written rules |
| What it did | The owner saw it | A record of every run |
| Which version ran | Rarely matters | Known for every run |
| Keys and access | One person’s accounts | Each tool’s own keys, people signing in with company accounts |
| Cost | One bill | Per run and per customer, with a cap on each turn |
Why is a personal assistant safe enough for one person?
Because the person is the control. They asked for the task, they see the draft before it goes, and if it books the wrong flight, they are the one who notices and fixes it. The risk and the oversight sit with the same person.
Why not give that assistant the company’s accounts?
Because nobody watches it the same way. An agent your business runs works at night, in many conversations at once, for customers who never see its steps. Full access with one person’s keys is a fair choice for that person. The same setup for a company means one leaked key or one bad turn reaches every customer.
For example: Acme’s founder has a personal assistant that drafts replies in their own inbox, and they read each one before it goes. Acme’s order-desk agent answers customers at night, and nobody reads along. The same model could run both. Only the order desk needs its oversight written down: a refund over the limit waits for the support lead, and every run is on record.
Who says yes before a business agent acts?
Named reviewers, under written rules. Reading data waits for no one. A refund waits for a reviewer. A post on the public status page waits for a senior one. The rules hold for every agent, not only for the agents whose authors remembered to add them. More in Approval fatigue.
The yes goes before the action. An email to a customer can’t be unsent, so approving it afterwards is only a record.
How do you know what a business agent did?
From a record of each run, written as it happens: each step, its input and output, and who approved what. That record is what the agent did, not what the model said it was doing. It is also what an auditor, or an upset customer, will ask for.
Which version answered that customer?
On a laptop, it hardly matters. In a business it does, because the prompt changed on Tuesday and the complaint is about Monday. Each agent version should pin the exact tool versions it uses, so a run traces back to exact code. A new version can then go live for one customer first, and go back in one step if it is worse.
Who can see whose work?
Each customer’s runs, conversations and approvals belong together, with what they cost, apart from every other customer’s. Your people sign in with your company’s accounts, under its multi-factor rules, and when someone leaves, removing them is one step, not a hunt through old API keys.
What does a business agent cost, and for whom?
A personal assistant has one bill. An agent your business runs needs a cost per run and per customer, and a cap on each turn, so a loop at 3 a.m. stops at a set spend instead of at the end of the month.
Where Kindgi fits
Kindgi is an agent framework for production: your coding agent writes the tools, agents and flows in your own code, and Kindgi runs them and keeps every step on record. It’s built for the second kind of agent. Approvals go to registered reviewers, with rules that hold for every agent: which tools always ask, and the lowest reviewer role that may decide. Every run has a journal of its steps. A published agent version locks its tools, and a new version can be pinned for one org or project, and an earlier one pinned again to go back. Orgs and projects keep each customer’s runs and costs together, people can sign in through your identity provider, a budget caps each turn, and a tool gets its keys on each call without them appearing in your code or config.
The guides: decide an approval, set approval rules for every agent, read the journal, agent and tool versions, release an agent version, organize work by org and project, set up SSO, set an agent’s budget, cost per run and per customer and give a tool a secret.
How this was written: a coding agent drafted it from our docs and our code. We checked every claim, edited it and said yes. We publish articles like this partly because we want you to find us, including through AI assistants. More in How we write our posts.