By KYN AI Advisory Team — AI implementation specialists, Singapore
Use a stateless agent when each request stands alone: classify this email, extract this invoice, draft this reply. Use a stateful agent when the work spans steps or days: chase an invoice at 3, 14 and 30 days, track a quote through approval, or handle a case with several messages. Most SME work needs a mix. Keep the agent stateless and put the state in a database you control, so you can see it, correct it and audit it.
What do stateless and stateful mean?
Stateless. The agent receives an input, produces an output and keeps nothing. Run it again with the same input and you expect the same kind of result. Nothing carries over.
Stateful. The agent depends on what happened before. It reads a record of earlier steps, acts, and writes the new state. A reminder that fires on day 14 only makes sense if something stored that day 3 passed without payment.
Workflow vendors draw the same line when they describe memory for agents. The practical question is where the state lives, not whether it exists.
Which tasks are stateless?
Look for tasks with a right answer that depends only on the input.
- Sorting a reply into interested, not now, wrong person or unsubscribe.
- Extracting date, supplier, amount and tax from a receipt.
- Translating a message between English and Bahasa Indonesia.
- Drafting a first line from a given company page.
- Turning a comparison table into a client PDF.
These are cheap to run, easy to test and easy to scale. You can run a thousand in parallel. A failed run is repeated without harm. In KYN systems, sorting a reply costs about S$0.01 and drafting a first line about S$0.02 per email, figures from our live systems that depend on the model and text length.
Which tasks are stateful?
Look for time, sequence or accumulation.
- Receivables chasing across several days.
- Approvals that wait for a person.
- A sales conversation over weeks.
- Month-end close, where each step depends on the one before.
- A daily report that compares today with yesterday.
Here the agent needs to know where it is. Without that, it repeats a reminder, skips a step or contradicts what was said last week.
How do the two compare?
| Factor | Stateless | Stateful | |---|---|---| | Testing | Input in, output out | Needs scenarios across time | | Failure recovery | Run again | Resume from stored state | | Scale | Parallel | Needs locking on the same record | | Audit | Log the call | Log every state change | | Cost | Lowest | Adds storage and logic | | Typical risk | Wrong answer | Wrong answer plus a wrong state carried forward |
The last row is the trap. A stateless error ends with the run. A stateful error persists and shapes the next run.
Where should the state live?
Not inside the model, and not in a long chat history. Put it in tables with a clear shape: the case, its current step, the next due date, the owner and the log of what happened. We describe the tables in Postgres as the agent's memory.
This design has four benefits.
- Visible. Your team can open the record and see the state.
- Correctable. A person can fix a wrong state with one edit.
- Recoverable. If a run fails, the next one resumes from the stored step.
- Governable. You apply row-level security and approvals to the state itself.
Agent frameworks that hold state in memory or in a vendor's hosted store are harder to inspect. If the vendor changes the format, you lose the history.
What goes wrong with stateful agents?
- Drift. The stored state stops matching reality, for example a customer paid by bank transfer and nobody marked it. The agent chases a paid invoice. Reconcile state against the source of truth on a schedule.
- Double runs. Two runs act on the same case. Use a lock or a status field that only one run can move from "ready" to "working". See webhooks, retries and idempotency.
- Stale context. The agent reads old notes as current fact. Give facts a validity date.
- Silent escalation. The state says "waiting" for weeks. Add a maximum wait and a flag to a named person.
Our own books show the pattern: receivables are chased at 3, 14 and 30 days, driven by a due date and a status in a table, with the message itself waiting for a person to approve.
How do you choose for a new project?
- List the tasks. Mark each as input-to-output or as a sequence over time.
- Build the stateless ones first. They are quick wins and need little design.
- For each sequence, draw the states on one page: start, each step, end, and who owns each wait.
- Store the states in your database. Make the agent read, decide and write.
- Add a person's approval wherever a message goes out or money moves.
What does a stateful flow look like step by step?
Take a quote follow-up agent (illustrative). The agent keeps no memory of its own. The database does.
- A quote is sent. The system writes a case with status "quoted" and a follow-up date.
- On the follow-up date, the agent loads the case: the quote, the customer, the contact history and the rules.
- It drafts a message. A person approves it.
- The system records the message, sets status "followed up" and sets the next date.
- The customer replies. The agent loads the same case, reads the reply and proposes the next step.
If the agent crashes at step 3, nothing is lost. The case still says "quoted" and the next run picks it up. If you replace the model next quarter, the state stays where it was.
This is the practical case for keeping state in the database: you can inspect it, correct it and audit it. State inside a prompt or a chat history cannot be queried.
How do you keep a stateful agent honest?
Treat state as data with an owner. Give every case a status from a short list, and allow only defined moves between statuses, such as quoted to followed up to closed. Reject any change that skips a step. Add a timeout, so a case stuck for more than a set number of days appears on a list for a person. Store the agent's proposal separately from the decision, so you can see later where a person overrode it. Run a monthly check for orphan cases and conflicting statuses. These checks are small queries, and they catch most of the drift that makes stateful systems unreliable over time.
Where KYN fits
KYN builds agents that are stateless in logic and stateful in data: the agent reads the case, acts within rules and writes the result, while the state lives in a database in the client's own cloud account. Agents have their own restricted accounts, every action is logged with the actor, and outbound messages, money, filings and deletions wait for a named person.
The first 14 days are a review of your stack and interviews with your team. A full build ships in under 90 days. See finance systems and operations systems.
Frequently asked questions
Is a stateful agent more intelligent than a stateless one?
No. Statefulness is about memory, not capability. A stateless agent can use a strong model. A stateful agent just has stored history to work from.
Can I start stateless and add state later?
Yes, and it is a good path. If the agent already reads and writes through a database layer, adding a case table and a step field is a small change.
Where do vendors store agent state?
It varies by product: in the vendor's hosted service, in your database, or in the conversation context. Ask where the state sits, whether you can export it and who can read it.
Checked 30 October 2026.
Curious whether Marketing agents fits your business? Talk to KYN on WhatsApp — no forms, just a conversation.
