u/LolaCronje

For those running agents in production, I’m curious about the moment you went from:

“the agent recommends what to do”
to:
“the agent actually does it.”

Once an agent can change customer data, issue a refund, modify permissions, trigger workflows, write into internal systems, etc., what started breaking that you hadn’t anticipated?

I’m especially curious about the boring operational cases.

The API times out, but the write may have succeeded.

The agent retries.

Two systems disagree about what happened.

A human corrects something afterwards.

Six months later someone wants to know exactly why one action happened.

How are you dealing with those cases today?

Do you have a dedicated record of agent actions, rely on traces and application logs, build this into the backend, or something else entirely?

I’m doing research with teams that already have agents performing real write actions in production.

If you’re working on this, I’d really appreciate hearing how you approached it. DM is welcome. I’m also happy to send a few specific questions instead of asking for a call.

I’m trying to speak with people who have crossed a specific line with AI agents.

Not agents that summarize information or recommend an action.

I mean agents that can actually change something in a production system.

For example:

- update a CRM or ERP
- modify an order
- issue a refund
- create or change a ticket
- write to a database
- trigger a workflow
- call an API that creates a real side effect

I’m interested in what changes once you give an agent that level of autonomy.

How are you handling retries when the outcome of the first attempt is unclear?

If someone disputes an action months later, can you reconstruct what the agent knew, what it decided, what it sent, and what actually happened?

Do you treat agent actions differently from ordinary backend operations, or has your existing infrastructure been enough?

And who owns this internally?

I’m specifically looking to learn from teams already dealing with this in production.

If that describes what you’re working on, I’d love to compare notes. Happy to do a short call, or I can send a few questions over DM if async is easier.

I’m trying to talk to people who have crossed a pretty specific line with AI agents.

Not copilots that suggest an action.

Not agents that prepare something for a human to approve.
Not read-only agents.

I mean agents that are actually allowed to change state in production.

Things like updating a CRM or ERP, changing an order, issuing a refund, modifying permissions, triggering workflows, writing to a database, or calling APIs with real side effects.

I’m curious what happens operationally once you get to that point.

For example:

An agent says it issued a refund. How do you establish whether it actually happened?

A request times out and the agent retries. How do you know the external action didn’t happen twice?

Someone questions one particular action months later. Can you reconstruct what the agent saw, what it decided, what it sent, and what actually changed?

And who owns this internally once agents are doing consequential things? The agent team, platform, security, risk/compliance, someone else?

I’m especially interested in hearing from people who are already dealing with this in production, rather than discussing how it theoretically should work.

If you’re running agents with real write access, I’d love to compare notes.

Happy to grab a virtual cofee for 20 minutes (coffee is on me) but I also know nobody needs another meeting. If async is easier, I can just send you a handful of questions over DM.

Feel free to DM me, or share what you’ve learned in the comments if you’re comfortable doing so.

For one workflow, a table in the application database looks hard to beat.

Give each important write an ID. Store the request, the result and a few timestamps. Add a status for the awkward cases where you don’t yet know whether the outside system completed the action.

That is cheap, easy to understand and already sits next to the business logic.

I’m interested in teams that started there and later turned it into a proper service.

What was the first requirement that forced the change?

Not the final list of features you ended up with. The actual moment when the table stopped being enough. Maybe another team needed it. Maybe provider callbacks, retention, permissions or old-schema support became painful. Maybe it stayed a table and worked perfectly well.

The safest design I’ve seen keeps the agent well away from payments, refunds and other important writes.

The agent calls a normal backend service. That service checks permissions, handles retries, updates the database, talks to the provider and reconciles the result. The agent is just another client.

In that setup, maybe there isn’t a new “agent accountability” problem at all. You already have the agent trace for the decision and the backend record for the action.

For people running this architecture, has it been enough when one case gets questioned months later, or do you still end up joining the agent decision, backend operation and provider result by hand?

I’d especially like to hear from teams where the ordinary backend record genuinely solved it. That may be the cleaner answer.

One answer I keep getting is that the hard part isn't writing the rows. It's living with someone else's abstraction after your workflows change.

That makes sense. The core can be pretty small: an operation ID, the exact request and result, append-only status changes, and a thin adapter for each external system.

But I've also heard from teams that spent most of their agent engineering time on retries, reconciliation, approvals, history and all the other plumbing around the actual agent.

So where's the line for you?

If you built this layer yourself, what would an external primitive have to get right for you to keep it rather than replace it in a year or two?

Open format? Self-hosting? Raw-event access? No opinionated workflow?

Or is this simply too close to the product to outsource?

I’ve been trying to find the honest boundary here.

Assume the team isn’t sloppy.

Agent/tool calls are instrumented.

Trace IDs propagate through services.

Important business state is in the application DB.

Logs go somewhere like Datadog/Splunk and can be archived long-term.

At that point, what can you still not answer when somebody questions one agent action six months later?

If the answer is “nothing, that stack is enough,” I’d genuinely like to hear that too.

I’m trying to separate a real infrastructure gap from things that are basically solved by doing observability properly.

Not asking about LangGraph/CrewAI/etc.

I mean the stuff nobody puts in the demo:

idempotency
approval state
retries
action ledgers
reconciliation jobs
policy versions
tool-call history
state snapshots
audit tables
human escalation

I keep seeing teams start with one tiny safety mechanism and slowly accumulate half a platform around it.

For people who’ve actually gone through this, roughly how much engineering did it turn into?

A couple days and done?

A few weeks?

Someone basically owns it now?

And which part, if any, would you absolutely not build yourself again?

People often say risky agent actions are safe because a human approves them.

But what did the person approve?

A message saying “issue a $200 refund”? The exact account and amount? The actual request that was eventually sent to the tool?

Suppose the workflow pauses after approval, reloads some customer data and rebuilds the request before executing it. The final action may be slightly different from the one the person saw.

The approval still exists in the logs, but it no longer proves very much.

How tightly are people binding human approval to the action that eventually happens?

Retrying a read is easy. Retrying a write is where I get stuck.

Say an agent calls a payment, refund or account-update API. The external system completes the action, but the workflow times out before saving the response.

When it restarts, it sees an unfinished step. Retrying might repeat the action. Skipping it might leave the workflow in the wrong state.

I’ve been comparing the usual answers: idempotency keys, workflow checkpoints, checking the target system before retrying and sending ambiguous cases to a person. Each seems to work until the agent touches several systems or one API has weak retry behaviour.

What information do you rely on to decide whether to retry, continue, undo something or stop?

Most agent demos stop at the trace.

Tool called. Response received. Task complete.

But say the customer disputes the refund three weeks later. Can you show the exact account, amount, approval, request sent to the provider and what changed afterward?

Or do you mainly have a transcript where the agent says it worked?

I’m less interested in getting the model to explain its reasoning here. I’m interested in the evidence from the systems it touched.

Once an agent is working across a CRM, billing platform and internal database, how are people keeping one reliable account of what actually happened?

Genuine question, not a hot take.

Every agent deployment I read about mentions human in the loop as the safety story. I keep trying to work out at what volume that stops being real.

Rough arithmetic. If your agent handles 5,000 decisions a day and one person reviews them, that's about 5.7 seconds per decision across a full eight hour shift with no breaks. Nobody is reviewing anything in 5.7 seconds. They're clicking approve.

This isn't new. Lisanne Bainbridge wrote about it in 1983 (Ironies of Automation) and aviation has decades of research on it. Put a person in a supervisory role over a system that's right almost all the time, and their attention degrades until they're worse than no supervisor at all, because now everyone downstream assumes it was checked.

So it looks like there are only two honest versions:

1. A human genuinely commits every action, which caps your throughput at human speed. Completely valid, but then say that out loud rather than calling the system autonomous.

2. The human is there for liability reasons and isn't really reviewing, in which case calling it oversight is a stretch.

I don't think option 2 is dishonest exactly. It just feels unexamined. Everyone puts the human in the architecture diagram and nobody does the arithmetic on what that person can actually process in a shift.

Curious whether anyone here has landed somewhere better than those two.

Sampling? Only reviewing above a confidence threshold? Reviewing after the fact rather than before? I'd be interested in what actually works in practice rather than what looks good in a diagram

Most agent reliability content I see is about the agent doing somethingdumb. Hallucinating a tool call, looping, picking the wrong action.

The one I keep thinking about is different, and I rarely see it come up.

The agent does everything right. Reads the state, makes a correct decision given that state, writes the result. No error, no exception, nothing to retry. Then the state it read changes before anyone commits or reviews the outcome.

Rough shape:

14:03 agent reads the record, decides, writes

15:20 the underlying data changes (someone amends a transaction, a screening list refreshes, a customer pays)

16:00 a human approves the agent's output

Every step worked. The output is wrong. Nothing errored anywhere.

We had a name for this long before LLMs. It's a read-modify-write with no lock. The difference is we used to solve it inside one database with transactions, and now the "read" is a model's understanding of the world spread across four systems, and the "write" is a payment.

What bugs me is that retries don't help, because nothing failed.

Monitoring doesn't help, because nothing errored. Evals don't help, because the decision was correct at the moment it was made. Your logs will faithfully record a clean, internally consistent, wrong result.

And it gets worse as the agent gets better. A bad agent gets caught in week one. An agent that's right 99 percent of the time buries a small number of confident, plausible errors inside thousands of correct ones, which is much harder to find.

Am I overthinking this? For anyone running agents that write to real systems, do you do anything specific about it, or is it accepted as noise?

I've seen idempotency keys and compensating transactions come up, but that feels like it solves the "run failed" case rather than this one