Skip to content
Technical deep diveSerial number MSK–T/001

Agents in production.

What actually changes when a model stops being a demo and starts doing work.

By Marcos Ruiz3 min read
  1. Inputs
  2. Preparation
  3. Model
  4. Guardrails
  5. Review queue
  6. Monitoring
  7. Hand-over
On this page
  1. The demo is not the product.
  2. What changes when the model starts doing work.
  3. What we build instead of a demo.

The demo is not the product.

A demo answers one question: does the idea work at all. It runs on curated examples, in a quiet room, with someone at the keyboard who knows exactly what to type. None of that describes a Tuesday afternoon in a claims department.

Production is a different environment. The inputs are messy: scanned documents, half-finished emails, a spreadsheet someone edited by hand last year. The user does not know the right phrasing. The system has to work anyway, or say clearly that it cannot.

What changes when the model starts doing work.

Inputs → Guardrails

In a demo, a mistake is a talking point. In production, a mistake reaches a customer, a contract or a machine. That shifts the whole design: you stop optimizing for the best answer and start optimizing for the worst one you can survive.

Review queue → Monitoring

A model that only exists in a notebook never drifts, because nobody is watching it meet new data. Once it is in your environment, the inputs change under it: new suppliers, new phrasing, new edge cases nobody wrote a test for. Without monitoring, you find out from a complaint instead of a dashboard.

Hand-over

Someone on your team has to own the system after we leave: read its logs, retrain it, decide when to turn it off. We design for that hand-over from the first sprint, not the last one.

None of this is exotic. It is the same discipline any production software already needs, applied to a system that can be confidently wrong in a new way each week. The tooling looks different; the standard should not. A team that treats an agent like a normal service, with the same review and the same on-call habits, tends to have fewer surprises than a team that treats it like magic.

What we build instead of a demo.

We start with the narrowest version of the task that is still useful: one document type, one decision, one team. We put it in front of real users on real data before we add anything else. If it fails, it fails small and it fails early, where it is cheap to fix.

Then we add the parts that never show up in a demo: logging, retries, a way to flag a wrong answer, a person who reviews the flagged cases. All of it is what makes an agent survive contact with a Tuesday afternoon.

Network of connections spreading from Valencia across the globe

Working on something *like this*?

Tell us what you are building. We reply with a plain answer on whether AI is the right tool.

Talk to usor write to hello@maistik.studio