Custom AI agents for business, and the permissions they should not have

What is a custom AI agent for a business?

A custom AI agent for a business is software built around one of your own processes and connected to the systems you already use, with AI making the judgement calls inside limits you set. It can read, draft and, where you allow it, act. Anything involving money, deletion, access rights or messaging a group of customers stops and waits for a person.

Someone on your side still has to decide which process is worth automating, what a good output looks like, and who handles the cases the agent should not touch. We do not skip that conversation, because every later decision depends on it.

What have custom AI agents done for our clients?

The results below come from our work page, and each figure stays with the case it came from. The table shows selected cases with published results, not all of them, and we do not average them, because they measure different things.

Client	What the agent does	Published result
Real estate business, USA (Texas)	Inbound and outbound voice agents, running 500+ calls a day with automatic categorisation into the CRM	$114k saved per year, lead qualification up 100%, 24/7 inbound coverage
Another real estate business, USA (Texas)	AI calling for investor outreach	Investor leads at $19.79 cost per lead, 40% higher conversion after AI calling, 60% lower outreach cost
RTO business, Australia	Delivery line rebuilt as a single audited automation of 34 AI nodes	94% gross margin, from under 35%, at about $4 of AI cost per full unit pack
Eye care business, USA (New York)	AI booking conversations	82 conversations via AI booking, at $0.36 cost per click
Building materials business, Germany	One system in place of three disconnected tools, with a CRM behind it	50+ leads on $2k spend

Not every row has a before-and-after baseline. The RTO row and the second real estate row do. The eye care, building materials and first real estate rows report what the system produced or saved, without a like-for-like comparison, and you should read them as that.

Two of the figures need a further caveat. The $114k a year is a saving set against the human calling team the voice agents replaced, which is a different claim from new revenue. The 94% is a gross margin measured on the same delivery line before and after, which makes that comparison unusually clean.

The eye care row needs its own plain sentence. The 82 conversations and the $0.36 per click are activity, not confirmed bookings.

The word agent covers four very different things

Vendors use one word for systems with completely different risk profiles, which is why demonstrations impress and deployments disappoint. There are four rungs.

• 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.

The benefit of an agent over a chatbot sits on the second to fourth rungs. Answers are current, repetitive work moves off your staff, and the system is awake when they are not. The cost is that you now have something that can be wrong inside your own records, which is what the rest of this page is about.

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.

Tools are also where integration with your existing systems happens. Each tool is a connection to your CRM, calendar, accounting package or phone system, so the honest question for any project is which of those systems expose an interface software can use, and how well it is documented.

• 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.

This is the continuous improvement part of an agent, and it is the part that is skipped most often. 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

How do you create AI agents for a business?

You start with one process, not with the technology. Pick the job that eats the most staff time and has an output you can check, such as qualifying leads on the phone or assembling an audit-ready training pack. Map how it is done by hand today, build the agent to do that job, test it against the human version, and keep a person on the exceptions.

The RTO business in Australia shows the order. Every training pack there had been built by hand, and delivery was the cost. We rebuilt that line as one audited automation of 34 AI nodes, with each AI step visible and inspectable rather than hidden in a single prompt. Then we compared the margin on the same line before and after.

Once one agent has proved itself, you add the next process and connect them. A voice agent becomes more useful when it writes to the same CRM your reporting reads from, as set out on our AI business dashboard page, and the same logic carries into running operations and producing content.

How is a custom agent different from using ChatGPT?

A general chat tool answers whoever types into it. A custom agent is wired into your phone lines, CRM and documents, follows your rules, and can run without anyone prompting it. The trade-off is that it has to be built and looked after. We compare the two directly on ChatGPT vs custom AI for business, including the cases where the general tool is enough.

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.

Two more cases belong here. A process that happens rarely has no volume to save against, so the build will not pay back. And a job that is mostly judgement or relationship should stay with a person, with the agent preparing the ground. We also do not run everything in a business through AI, and an agency that tells you to is selling, not advising.

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. You own what we build, and 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 person who decides the architecture on this kind of build was Director of AI for a United States real estate company beforehand. That is why we settle the permission boundary, the approvals and the replay log before anything is prompted, because that is where a convincing demonstration and a working deployment part ways.

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.

What does a custom AI agent for a business cost?

Agent builds have no published price. We quote each one after you describe the process, and the quote is driven by two things: how many systems the agent has to connect to, and how much checking its work needs. A narrow agent over one well-documented system and a wide one that writes into half your stack are different jobs and are priced as such.

How we bill depends on the build. Some projects are a one-time build, some are a monthly service, and some are both. Monthly services stop in any month, with no lock-in. If a new idea comes up during the work, it becomes the next phase, quoted first and never added quietly.

To get a quote, tell us the one process you would most like to stop doing by hand: who does it today, how often it happens, and what a good output looks like. Our services page shows how the builds are arranged.

Common questions

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

A chatbot returns text, while an AI agent calls tools that read from and write to real systems. That is why permissions, not model quality, are the main design question for an agent.

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

A custom AI agent can reach your own systems, such as bookings, inventory and customer history, and update them. An off-the-shelf assistant knows language but has no connection to any of those.

Is it safe to let an AI agent write to our systems, and how do you stop it doing something unexpected?

It is safe when the tools make the unwanted action impossible, with narrow validated inputs, separate read and write credentials and a hard refusal above agreed thresholds. Prompt instructions are only requests, so anything touching money, deletion, access or group messaging needs a person to approve the exact change.

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

A custom AI agent build runs in a fixed order: map the process, set permissions, build the tools, test against recorded cases, then run with approvals. We give no single timing, because it depends on how many systems the agent must reach, and a wide build is split into phases.

How do you know whether an agent is working?

An agent is working when it passes a set of recorded real cases on every change and few of its actions are later reversed by a person. Someone should also read a sample of its runs each week, because an unreviewed agent degrades without an error message.