By KYN AI Advisory Team — AI implementation specialists, Singapore
Most first business agents fail for seven reasons, and none is the model. They fail because the scope is vague, permissions are wide, nobody approves outbound actions, the data is stale, there is no log, there is no baseline, and no one owns the result. Each has a design fix that costs little if you apply it on day one and a lot if you retrofit. This article lists them in the order they bite. It reflects design lessons from building agents for sales, marketing, operations and finance, not a confession about any one project.
Mistake 1: Starting without a baseline
If you do not measure the manual process first, you cannot say what the agent changed. Teams launch, feel relief and cannot answer the owner's question six months later: "What are we getting for the retainer?"
Fix. Time the manual version for two weeks. Record minutes per unit, units per week and the last quarter's errors. Put them on one page. See our method for auditing admin hours.
Mistake 2: Scoping the agent as a person
"An agent that handles our sales" is not a scope. It invites the agent to do everything and gives you no way to check any of it.
Fix. Write the scope as verbs on nouns, each with a checkable result: "Read each incoming reply and label it as interested, not now, wrong person, unsubscribe or question." One job, one test. A first agent should have one to three jobs.
Mistake 3: Giving it your login
The fastest way to start is to put your own credentials into the tool. It is also the fastest way to cause damage. The agent then acts as you, with your access to every system, and the log says you did it.
Fix. The agent gets its own restricted account with only the permissions its jobs need. Named accounts for people. No shared logins. Every action logged with the actor, so "the agent did it" and "Maria did it" look different in the log. Our security checklist before production goes through this in more detail.
Mistake 4: Letting it send without approval
An agent can send a hundred messages before anyone notices one is wrong. A message in your name is a commitment, and you cannot unsend it.
Fix. Outbound messages, money, filings and deletions wait for a named person. The agent drafts into a queue. The reviewer sees the draft, the source and an approve or edit button. Approval is fast when the queue is well built. For the full pattern, see approval gates for high-risk actions and whether it is safe to let an agent email customers.
Mistake 5: Trusting stale data
An agent writes fluently from whatever it is given. If the CRM says the contact works at a company they left a year ago, the draft will say so confidently. Fluency hides staleness.
Fix. Cite the source and its date in every output. Add a freshness rule: a record older than a set age is flagged, not used. Run a sample check before launch: 50 records, compared by hand to reality. Fix the data, then the agent.
Mistake 6: Skipping the log
When something goes wrong, the first question is "what did it do, and why?" If the answer is a guess, you cannot fix the cause, and you cannot tell the client or the regulator what happened.
Fix. Log every action: actor, time, input, output, rule applied and who approved. Make the log append-only. Build it in the first slice, not after. A log added later has gaps exactly where the early mistakes happened.
Mistake 7: Leaving it without an owner
A workflow without a named owner decays. Rules go stale, the review queue grows and the numbers drift. Nobody notices until a client does.
Fix. Name one person per workflow. They read the weekly numbers, decide on rule changes and own the review queue. Record their name on the workflow page. When they leave, the role passes on explicitly.
How do the seven map to cost?
| Mistake | Cost when found late | |---|---| | No baseline | Cannot justify renewal | | Vague scope | Rework of prompts, rules and screens | | Shared or personal login | Security incident, unclear blame | | No approval gate | Wrong message to a client | | Stale data | Confident wrong output | | No log | Cannot investigate or explain | | No owner | Slow decay of all of the above |
None is expensive to prevent. All are expensive to repair.
How do you test an agent before it goes live?
Test it on real, old cases whose answers you already know.
- Collect 100 past cases. Replies, bills, leads, whatever the agent handles. Include the awkward ones: forwarded messages, other languages, attachments, blank fields.
- Run the agent in draft mode. Nothing is sent or written to the live system.
- Have a person label the same 100. Compare. Group the differences by type, not by count alone. One missed unsubscribe matters more than ten harmless label changes.
- Try to break it. Feed it a reply that contains instructions, an empty record and a duplicate. The agent should flag these, not obey or guess.
- Write down the pass mark before you look. For example, no missed unsubscribes and no wrong amounts. If you set the mark after seeing the result, you will set it to pass.
Repeat the test after any change to the rules or the model. A short test set that you keep and rerun is worth more than a long test you run once.
What does a sound first agent look like?
A small one. Pick a workflow with these properties:
- it runs often, at least weekly;
- a rule decides the right answer most of the time;
- a mistake is caught internally before it reaches a client;
- the result can be checked by a person in seconds.
Examples that fit: sorting inbound replies, drafting a first line from a cited source, reading a bill from an inbox into a register, building a daily department report. We run each of these in live systems, at unit costs of a few cents.
Start in draft mode. The agent writes into a queue and nothing leaves. Review a sample every day for two weeks. When the reviewers approve nearly everything unchanged, allow unattended mode for actions that are reversible. Keep the gates on the rest.
For a broader view of risks, see security risks before using AI for business and prompt injection in business AI agents.
Where KYN fits
KYN builds agents for sales, marketing, operations and finance with rules-based logic, and designs the seven fixes above into every system. Agents have their own restricted accounts, the database uses row-level security, every action is logged with the actor, and outbound messages, money, filings and deletions wait for a named person. Everything runs in a cloud account in your name, and you can revoke our role while it keeps running.
The first 14 days are a review of your stack and team. That is where we set the scope, the baseline and the owner. A full build ships in under 90 days. See security and infrastructure.
Frequently asked questions
How many jobs should a first agent have?
One to three. Each job should have a result a person can check in seconds. Add more after the first has run for a month with stable numbers.
Should the first agent run unattended?
Not at first. Run it in draft mode with review, then widen to unattended only for reversible actions once the output has held up.
Who should own the agent?
The manager of the team whose work it changes. They read the weekly numbers and own the review queue. An IT contact alone will not know when the output is wrong.
Checked 30 October 2026.
Curious whether Marketing agents fits your business? Talk to KYN on WhatsApp — no forms, just a conversation.
