On the first of September, La French Tech Bangkok filled a room on the thirty-first floor of Common Ground at Rama 9 for the second episode of its AI Agent series, From AI That Talks to AI That Acts. The speaker was Nicha Suebwonglee, an entrepreneur and investor who runs a personal agent on an eight-gigabyte virtual server. Julien of Salesmind moderated. The evening ran on live demos rather than slides: a real inbox, a real Telegram window, a real smart-home account, things going wrong and being corrected in front of the room.
She opened with the distinction that did the work for the whole evening. "The key difference is agency." A chatbot stops when you close the tab. An agent takes multi-step action over minutes or hours and keeps running after you leave. It can be event-driven. It can run at three in the morning.
Then she proved it. An agent watching an inbox unprompted and classifying by urgency, catching a "call me ASAP" by cross-checking a calendar. A one-line prompt with nothing but a company name, returning structured research into a persistent knowledge base. A smart-home account reconfigured through a stored skill, the credential passed as a temporary share because "the path doesn't go through plain text."
CHANNELS email, Telegram, chat
|
v
SCHEDULER events and timers: runs while you sleep
|
v
AGENT <----> MEMORY + KNOWLEDGE BASE
|
v
HUMAN APPROVAL GATE
|
v
TOOLS anything that can change something
The stack she drew on stage, with the component most agent demos leave out: a human approval gate between the agent and anything it can change.
So the question is no longer whether agents act. They do, and the demos were not cherry-picked: one was corrected live on stage by a second agent. The question we left with is the next one along: what changes when the thing acting is acting on a business. Not on your own calendar, where a mistake costs an afternoon, but on a company's money, customers and records, where a mistake has someone's name on it. Almost everything below is her material, followed one step further.
It starts with a goal, not a tool
Nicha closed with a sequence rather than a checklist: define the goal, then define what matters and what the guardrails are, and let that decide which harness you pick, cheap and lean or capable. Goal first, tool last.
1. GOAL what outcome, for whom
|
v
2. GUARDRAILS what matters, what it must never do
|
v
3. HARNESS lean and cheap, or capable
(chosen last, because 1 and 2 decide it)
It sounds obvious in a room of builders. It is not what happens in the meeting where work actually gets commissioned.
In our experience clients do arrive with goals, and the goals are almost always sound. Help me build a database to find potential buyers. I need a community management system. I need a booking system for my gym. Every one is a real commercial problem stated in commercial language, by someone who understands their business far better than we do.
What arrives alongside the goal is a solution already attached to it: often reasonable-sounding, frequently not optimal, sometimes not addressing the goal at all. The job in the first meeting is not to price that solution. It is to separate the two, gently, and check whether the thing being asked for is the thing that produces the outcome being described.
We will put our name to the mistake on the other side of that table, because we have made it. We have started too complicated and too expensive: presented with a goal, we built the architecture the finished goal implies rather than the smallest thing that produces the outcome, then discovered in month two that the client's real usage would have taught us which half was necessary if we had let it. Building up organically is not a lack of ambition. It is how you find out what the requirement actually was, before it costs anything to change.
What it takes to let something act
Nicha's architecture included that human approval gate, and she was explicit about the role humans keep: judgment, and the conflicts and exceptions that policy cannot resolve, illustrated with an airline dispute where the AI simply follows the rule because the rule is all it has.
This is the component that matters most once the acting is on someone else's business, so we hold a firmer version of it as a design conviction rather than a compromise: AI does not get write permissions. Not at the start. A human approves each action while the model and the development team are still learning where the real decision points are. In the first weeks neither of them knows, and the gate is how you find out. What the gate produces is not only safety. It is a record of every judgment a person made, which is the specification you did not have when you started.
Then you make it deterministic. Everything that can be a rule, a lookup, a function or a constraint should be one. What is left, the genuinely ambiguous residue that requires reading context rather than applying policy, is where the model reasons, and where the agency she described earns its keep.
A. THE MODEL ORCHESTRATES EVERY STEP
input -> model -> model -> model -> model -> output
every step: tokens, cost, a chance to be wrong
B. THE MODEL DECIDES ONLY WHAT A RULE CANNOT
input -> rule -> lookup -> MODEL -> function -> output
|
only the ambiguous call
That residue is smaller than it looks from inside a demo, and the acting gets more reliable as it shrinks.
The failure we see most often is the mirror of this: using AI to solve everything. Running what is effectively an application inside the model's runtime (loops, state, branching business rules, arithmetic), all executed by a language model one token at a time and billed accordingly. It works in a prototype. It is ruinous in production, and when it breaks you cannot tell whether the logic is wrong or the model simply had a bad day.
What kind of acting a business actually needs
Nicha's cost answer was the one the room needed, and nearly every question that night came back to spend in some form: put the right agent to the right job, because most tasks do not need the smartest agent. An orchestrator on a strong model, sub-agents on cheap ones. Skills kept small and numerous rather than bundled, because bundling costs tokens on every call.
We would extend it one step in the direction the section above points. Route by model, yes, but first ask whether the step needs a model at all. The cheapest sub-agent is still slower and less predictable than the function call it replaces.
There is also a question of rhythm, and this is where a business diverges from a personal setup. Nicha named persistency repeatedly as the real differentiator, always-on and event-triggered, and she is right that it is what separates an agent from a chat window. But most of what a small or mid-sized business needs automated is not event-driven. It is scheduled.
| Rhythm | Fits work like | Cost to run and reason about |
|---|---|---|
| Event-driven, always on | An urgent email, a customer waiting, anything that cannot wait | Higher: it watches all the time |
| Scheduled | Invoices in batches, reconciliation on a cycle, a receipt queue four times a day | A fraction: it runs, finishes and stops |
A receipt queue running on a schedule is not a lesser version of an always-on agent; it is the right amount of persistency for that problem. Event-driven is what you reach for when the event genuinely cannot wait, and some can't, which is exactly why her inbox-triage demo worked.
One more, which is ours and which her architecture confirmed: atomic agents. Our recurring mistake has been carrying several contexts inside one agent while both building and running it. Single-minded agents are cheaper to run, easier to reason about and far easier to fix at two in the morning.
How you know it acted correctly
The demo we keep thinking about is the reviewer agent: a second, cheap agent that checked the first one's photo-geolocation answer, disagreed with it, and corrected it live. It was the most quietly impressive thing on stage, and the instinct behind it is exactly right: do not trust a single model's output on something that matters. We are adopting that instinct. Where we would place it differently is the layer.
| Reviewer agent at runtime | Scored test cases offline | |
|---|---|---|
| When it checks | On every call, live | Before delivery, after each change, then on a schedule |
| What it costs | A second model call every time | One test run per change |
| What it leaves behind | A corrected answer | A score you can show a client and compare next month |
| Best when | Every case is genuinely different, like a photo to geolocate | The same shape repeats, like most business processes |
The offline approach comes from a different talk in a different field: a standing set of test cases, hundreds of queries across personas, every answer scored into bands, re-run on each change and then on a schedule. It answers the same question, how do you know it is right, before deployment rather than during, and it produces a number. We are building toward it. Both are real controls: check at runtime when every case is different, as hers was; test the process when the same shape repeats.
How you know it was worth it
Nicha's stack diagram is the clearest we have seen drawn live. Everything an agent needs in order to act is on it. What is not on it is measurement. Nothing in that architecture establishes what the work cost before the agent existed, or reports what it costs after. That is not an oversight: it is a personal system with one user, and that user can simply tell whether it is helping. A business cannot. The owner who funded the build asks at month four what changed, and "it feels faster" renews nothing.
BEFORE THE BUILD THE BUILD SIXTY DAYS AFTER
baseline: -> agent, gate, -> re-measure:
how often? tools, tests same questions,
how long? same method
who does it today?
the difference is
the only number that
funds a second phase
We would add that layer underneath her diagram: a baseline taken before anything is built, and a re-measure sixty days after. Unglamorous, the first deliverable rather than the last.
It is also the honest answer to the objection the evening invites. Her setup ran on consumer subscriptions and a self-hosted eight-gigabyte box. No API bills. Anyone watching is entitled to ask why they should pay for more, and the answer is not that someone's runtime is better.
| What changes the economics | Personal agent | Agent acting on a business |
|---|---|---|
| Users | One, who is also operator and debugger | Several people with different permissions |
| Where the action lands | A chat digest | A system of record: books, CRM, bookings |
| Approval trail | Not needed | Someone can audit it afterwards |
| Proof it helped | The user can tell | A baseline and a re-measure |
| When it breaks on a Tuesday | The user fixes it | A named party is responsible |
A business that needs none of those five should genuinely build it themselves for twenty dollars a month. Some should.
What we are adopting
Concretely, from this talk:
- Governance as the first deliverable, not the last. Named before the build: what the system will refuse to do, who reviews what, where the audit trail lives. On a personal setup this is overhead. On a client implementation it is what makes the rest safe to deploy at all.
- Goal, guardrails, harness, in that order, out loud, in the first meeting. Saying it out loud is what surfaces the solution a client arrived already attached to.
- Model routing as a costed decision, not a default, with our own step in front of it: does this need a model at all?
- Small, many skills rather than bundled ones. Organising by token cost produces cleaner boundaries than organising by client domain.
- The checking instinct, placed offline: a scored set of test cases before delivery, re-run on a schedule after it.
- "No local installs" as a delivery rule. We asked Nicha from the floor how she decides between an MCP and a CLI. Her answer: CLIs are invasive for clients, the agent prefers writing code when the task is deterministic, everything runs on her server, and the client only ever sees a chat channel.
What we take from Nicha
The demo was the point, and it landed. What a capable harness can do now is further than most of that room expected, and watching an agent act, including watching one be caught and corrected by another, does something no description of the same capability does. We left impressed, and we are building with several of the patterns she showed.
What we take from it is where the effort goes next. For a personal system, the harness is the project: one user, one operator, one person who can tell whether it is helping. For a client implementation it is the easier half, and governance is the project. What the agent is allowed to change. Who approves each action while the decision points are still being learned. What gets written down as a result. How you prove it behaved correctly, and how you show it was worth doing.
That is the order we are putting it in from here: governance first, capability second. Not because capability does not matter, but because it is no longer the constraint. When the thing acting is acting on someone else's business, the interesting engineering has moved to everything that surrounds the model, and that is where a client's money should go.
If you have a goal, you have been sold a solution, and you are not sure the two match, that is the conversation we like having, and it is usually short.
Thanks to Nicha Suebwonglee for a talk specific enough to build on, to Julien for moderating and for the community he has supported since 2022, and to La French Tech Bangkok for running the kind of evening where the questions from the floor were as useful as the demos.
We shared a shorter version of this on LinkedIn: Agency is solved. Governance isn't.
FAQ
What is the difference between an AI chatbot and an AI agent?
Agency. A chatbot answers and stops when you close the tab. An agent takes multi-step actions over minutes or hours, can be triggered by events or a schedule, and keeps working after you leave.
Should an AI agent have write access to business systems?
Not at the start. A person should approve each action while the team learns where the real decision points are. The approvals become the specification, and anything that can be a rule is then turned into one.
Does a business automation need to run all the time?
Usually not. Most business work is scheduled, like invoice batches or reconciliation, and a scheduled run costs a fraction of an always-on agent. Event-driven agents fit work that cannot wait.
How do you know an AI agent was worth building?
Measure the work before the build (how often, how long, who does it) and measure it again sixty days after launch. The difference is the number that justifies the next phase.