Custom AI agents, and the permissions they should not have

The word agent covers four very different things

Custom AI agents for business are systems that do things inside your software rather than only talk about them. Each agent gets a defined list of tools, an order lookup, a booking calendar, a ticket system, and an account with limited permissions. Most of the build is deciding which actions it may take on its own and which ones have to stop and wait for a person.

Vendors use one word for a range of systems with completely different risk profiles, which is why demonstrations impress and deployments disappoint. Sorting them into rungs makes the buying conversation much shorter.

• Answers only. It reads material and replies. Nothing in any system changes as a result
• Reads your systems. It can look up an order, a balance or a booking, so its answers are current rather than general
• Proposes actions. It drafts the reply, prepares the record update, builds the refund, then waits for a person to approve
• Acts alone. It writes to real systems with no human in the path, inside limits set in advance

Most businesses ask for the fourth rung and need the third. The gap between them is not model quality, it is whether anyone would notice a wrong action before a customer did.

An agent is mostly its tools

The model gets the attention and the tools decide the behaviour. A tool is one specific thing the agent can do: look up a customer by phone number, create a draft invoice, check delivery slots for a postcode. The agent chooses which to call and with what arguments, and the quality of that choice depends almost entirely on how narrowly each tool has been described.

One broad tool that runs any query against the database will eventually be called with a query nobody imagined. Several narrow tools with validated inputs will not, because the shapes they accept are the only shapes they accept. Narrow tools also fail in ways a person can read afterwards, which is what makes the system operable rather than merely impressive.

• One job per tool, named for what it does rather than for the system it talks to
• Inputs validated at the boundary, so a malformed argument is refused instead of interpreted
• Write tools made repeat-safe, so a retry never creates a second order
• Every call logged with its arguments and its result, whether or not it succeeded
• Read access and write access held as separate credentials, so a read-only agent is read-only in fact

What an agent should never do without a person

This list is short and it is far easier to agree before anything is built than afterwards.

• Move money, change bank details, or issue a refund above an agreed threshold
• Delete anything. Archiving is reversible, deleting is a phone call to a backup provider
• Message a list of customers. Any outbound to more than one person goes through the same consent and template path a human campaign would
• Change prices or discounts, or alter terms in a document that has already been sent
• Grant access to a system, add a user, or widen a permission
• Commit the business in writing to anything, including a delivery date it has not checked

Prompt instructions are not permissions. An instruction never to refund above a limit is a request. A tool that refuses amounts above that limit is a control.

Approval without approval fatigue

The pattern that keeps the useful part of an agent while removing the frightening part is propose and confirm. The agent assembles the exact change, shows what will differ before and after, and a person approves it with one action rather than rebuilding the work themselves.

Reviewing everything equally is how that design dies. A queue where almost every item is obviously fine trains the reviewer to approve without reading, which is worse than no review at all because it manufactures a record of oversight that did not happen. Set the threshold where a human glance is genuinely worth something: value, irreversibility, or a customer being contacted.

The other half is making approval cheap. If confirming a change means opening three systems to check whether the agent was right, nobody will do it twice. The proposal has to carry the evidence with it.

• Approve, edit or reject in one place, with the before and after visible
• The source of each value shown, so the reviewer is checking rather than trusting
• Thresholds set by consequence, not by category, and reviewed once the real volume is known
• A record of what was approved by whom, because that is the trail an auditor asks for

You cannot operate what you cannot replay

A prompt change is a deployment, and most teams ship those with no test at all. The minimum that makes an agent maintainable is a set of recorded real cases with known correct outcomes, rerun every time anything changes: the prompt, the model version, a tool description, or the data underneath.

Build that set from actual traffic rather than imagined examples, and keep the awkward ones. The message with three questions inside it. The one that switches language halfway through. The one where the customer is wrong about their own order number. A small set of those teaches you more than a large set of easy cases.

Without a named owner reviewing a sample of runs, an agent drifts silently. A system it reads gains a new field, a supplier renames a product, and behaviour degrades in a way nothing logs because nothing errored.

• A stored case set, with the expected outcome written by a person
• Tool call logs complete enough to reconstruct any single run end to end
• The rate of agent actions a human then reversed, which is the clearest signal of miscalibration
• A named owner who reads a sample of runs every week, indefinitely

Where a custom agent is the wrong answer

If the systems it needs have no interface for software to use, the only route left is driving a screen designed for a person, which breaks whenever that screen changes and is expensive to keep alive. Read-only reporting is usually the honest scope until a real interface exists.

If nobody will review the agent's actions once the build finishes, the safe version is limited to drafting and the unsupervised version should not be installed at all. That is a staffing decision rather than a technical one, and it is better made before the budget is committed.

And if a single well-written rule would produce the same outcome, an agent is a more interesting way to get a worse result. It will be slower, harder to test, and it will occasionally choose differently for reasons nobody can reconstruct.

Who owns an agent afterwards, and when to build your own

An agent is a set of tools, a set of permissions and a record of what it did. All three are transferable, and on a Wobble build all three end up in your accounts. Model keys are yours, workflow definitions export, logs sit where you can read them, and the handover document lists every account and connection the agent depends on. Ownership is not a licence that lapses when the relationship does.

That matters more with agents than with a chatbot, because an agent takes actions. If you leave and the thing is still issuing refunds or writing to a CRM, you need to switch it off yourself at three in the morning without raising a support ticket. So the off switch is yours as well, and Wobble stays accountable for anything of its own that is still running.

The published evidence for what these do at scale is on the work page. Voice agents already run more than 500 calls a day for Big Texas Land Buyers with automatic categorisation into the CRM, and the AI Creator Program built for Palm Berries vets and processes influencer partnerships without a person reviewing each one. Moiz Khan decides the architecture on this kind of build, and was Director of AI for a United States real estate company beforehand, which is where the distance between a convincing demonstration and something that survives a real workflow stopped being theoretical for him.

Building in-house is a serious option and worth saying so on a page that sells the alternative. If you employ engineers who ship, the tool layer is not hard and the frameworks are public. What costs teams a quarter is the operational half: the permission boundary, approvals people do not learn to click through blindly, and a replay log detailed enough to answer why the agent did that. If somebody there will own those three, do it yourself.

Common questions

What is the difference between an AI agent and a chatbot?

A chatbot returns text. An agent can call tools, which means it reads from and writes to real systems and decides which tool to use and in what order. That difference is what makes agents useful, and it is also why permissions rather than model quality are the main design question.

What can a custom AI agent do that an off-the-shelf assistant cannot?

Reach your systems. A general assistant knows language but not your inventory, your bookings or your customer history, and it cannot update any of them. A custom agent is defined by the specific tools it is given and the limits placed on them, which is why most of the build effort sits in integration rather than in prompting.

Is it safe to let an AI agent write to our systems?

That depends on the tools it holds rather than on the model. Give it narrow tools with validated inputs, separate credentials for reading and writing, writes that are safe to repeat, and a hard refusal above agreed thresholds. Anything touching money, deletion, access rights or messaging a group of customers should require a person to approve the exact change.

How do you stop an agent from doing something unexpected?

By making the unwanted action impossible rather than discouraged. Instructions in a prompt are requests, and the control is a tool that refuses. Assume the agent will call every tool it has with the worst plausible arguments and check that the outcome is survivable. If it is not, change the tool set rather than the wording.

How long does it take to build a custom AI agent?

The conversational part is quick. What sets the timeline is integration and permissions: which systems it can reach, what credentials it gets, which actions need approval and what happens when a call fails. A narrow agent over one or two well-documented systems is a matter of weeks, and one that touches half the stack is scoped in phases so each part is proven before the next.

How do you know whether an agent is working?

Keep a set of real recorded cases with outcomes written by a person and rerun them on every change to the prompt, the model or the tools. Watch the rate of actions a human then reversed, because that is the clearest sign of miscalibration, and have somebody read a sample of runs each week. An agent nobody reviews degrades without producing a single error message.