AI Agents in Production: What Changes After the Prototype

A prototype can be impressive in an afternoon. Give a model a useful prompt, connect one source of company information, add a tool call, and suddenly it can answer a customer question, summarise a case, draft a response or update a record.

That moment matters. It proves the idea has some value. It does not prove the system is ready to run inside a business.

The move from prototype to production changes the question. The prototype asks whether the model can do this. Production asks something harder.

Can we trust the whole system to do this repeatedly, with the right data, the right permissions and a clear response when something goes wrong?

That is a much larger engineering problem. This article explains what actually changes when an AI agent moves into production, and why many teams discover that the model was only one part of the work.

A prototype proves capability. Production proves responsibility.

Most prototypes are built around the happy path. The input is clean. The user asks a sensible question. The required document exists. The API responds. The model chooses the right tool. The output looks convincing.

That is enough to learn whether an idea is worth pursuing. A production system has to deal with everything outside that path.

What if the customer is asking about two orders? What if the CRM is unavailable? What if the knowledge base contains two policies that disagree? What if the agent is allowed to read an account but not change it? What if a refund is above the employee approval limit? What if the model provider changes behaviour after an update? What if a response sounds correct but cites the wrong source?

The prototype does not fail because it was badly built. It fails as a production system because it was never designed to answer these questions. That is the real transition.

1. The workflow has to become explicit

A good prototype often begins with a broad instruction. Something like review this support request and help the customer. That is fine for exploration. It is too vague for production.

A production workflow needs a clear beginning, a clear end and a clear boundary around what the agent is allowed to decide. For a support agent, the real workflow might be:

1. Receive the new ticket.
2. Identify the customer.
3. Retrieve the relevant order.
4. Search approved support content.
5. Draft a response.
6. Check whether the request includes a refund, credit or account change.
7. Send ordinary responses automatically if confidence and policy rules are satisfied.
8. Route financial or sensitive actions to a person for approval.
9. Log the result and the sources used.

Now the team has something it can test. It also has something it can price, monitor and improve.

A vague AI assistant is difficult to operate. A defined workflow is much easier.

2. Integrations stop being demos and become production dependencies

Connecting an agent to a business system is easy when the only goal is to show that the connection works. Production adds another layer. The team has to decide what the agent can see, what it can change and whose authority it is acting under.

A CRM integration raises questions such as:

• Can the agent read every account, or only the accounts the user can access?
• Can it update a record, and which fields can it update?
• Should changes appear as the employee, a service account or the AI system?
• What happens if the update succeeds but the next step fails?
• How do we reverse an incorrect action?
• What is recorded for audit purposes?

This is why production AI becomes conventional software engineering very quickly. Authentication matters. Permissions matter. Retries matter. Rate limits matter. API behaviour matters. Data contracts matter.

The model may decide what should happen next, but ordinary engineering determines whether that action is safe and reliable.

3. Company knowledge needs ownership, not just retrieval

Retrieval augmented generation is often demonstrated by loading a set of documents and asking questions against them. That can work extremely well. The production problem is not simply whether the agent can retrieve text. It is whether the organisation can trust the source it retrieved.

Imagine that a support agent finds two refund policies. One was written last week. The other is three years old. Both are still indexed. Which one wins?

Now imagine that the old policy appears higher in the search results because its wording happens to match the question more closely. The retrieval system has technically worked. The business result is still wrong.

Production knowledge systems need decisions around:

• Which sources are authoritative.
• Who owns each source.
• How old material is removed.
• How access permissions are preserved.
• How quickly updates appear.
• How citations are shown.
• What happens when the system cannot find enough evidence.
• What happens when two approved sources conflict.

This is not a vector database problem. It is an information ownership problem. The technology should make that ownership easier to enforce.

4. Evaluation replaces testing by impression

A prototype is often judged by trying a few examples. The answers look good, so the team moves on. That approach breaks down once the agent is doing useful work every day.

Production needs a repeatable definition of good. For a support agent, that might include:

• Did it understand the customer request?
• Did it retrieve the right policy?
• Did it use the right account information?
• Did it avoid inventing information?
• Did it call the correct tool?
• Did it respect the approval rule?
• Did it escalate when the case was uncertain?
• Was the final response accurate and useful?

A useful evaluation set is not a collection of random prompts. It should represent the cases the business actually cares about. That includes easy cases, difficult cases and cases that should fail safely.

OpenAI describes evaluation as part of the move from a functioning agent toward reliability and optimisation,¹ and its own production systems use curated evaluations to catch regressions as behaviour changes over time.² That matches what we see in practice. Once the agent matters, evaluation becomes part of the product.

5. Human approval is often a feature, not a compromise

There is a tendency to describe agent maturity in terms of autonomy. More autonomy sounds more advanced. In production, that is not always true. The better design is often the one that puts a person in exactly the right place.

Consider a customer service workflow. The agent may be perfectly capable of reading the ticket, finding the order, checking the policy, calculating the refund and drafting the response. The business may still want an employee to approve the final refund.

That does not make the agent less useful. It may remove most of the manual work while keeping a person responsible for the consequential decision. OpenAI describes a similar pattern around its own internal coding agent, where technical boundaries and approval for higher risk actions sit alongside telemetry for agent activity.³

The important question is not whether the agent can act without a human. The better question is:

Which actions are safe to automate, and which actions deserve a person before execution?

Financial changes, contractual commitments, sensitive data, account permissions and irreversible actions usually deserve a more deliberate boundary.

6. Failure handling has to be designed before the failure happens

A prototype often stops when something goes wrong. A production agent needs to know what to do next.

Suppose the agent needs information from a CRM and the CRM times out. Possible responses include retrying once, waiting and retrying later, continuing without the information, asking the user for clarification, routing the task to a person, or stopping the workflow.

Those choices depend on the business process. There is no universal answer. The important part is deciding in advance. The same applies when:

• Retrieval confidence is weak.
• A tool returns unexpected data.
• A user asks for an action outside policy.
• Two systems disagree.
• An approval request expires.
• A downstream service is unavailable.

A production agent should have a useful failure mode. Silence is not one. Confidently making something up is definitely not one.

7. Monitoring has to include behaviour, not only uptime

Traditional application monitoring tells you whether the service is available. That still matters. AI systems need another layer, because the application can be technically healthy while the agent is becoming less useful.

The API is responding. The database is online. The queue is moving. But perhaps retrieval quality has fallen. Perhaps tool failures have increased. Perhaps a model change has made responses longer and more expensive. Perhaps more cases are being escalated. Perhaps users are correcting the agent more often.

Production monitoring should make those changes visible. Useful signals can include:

• Successful workflow completion.
• Escalation rate.
• Tool errors.
• Retrieval failures.
• Latency.
• Model usage.
• Cost per completed workflow.
• Human corrections.
• Evaluation scores.
• Policy violations.

The point is not to build a giant dashboard. The point is to notice when the system changes before the business discovers it through complaints.

8. Cost needs to be measured per useful outcome

Model pricing receives a lot of attention because it is easy to measure. For production systems, the better unit is usually the completed business task.

Imagine two agents. Agent A costs less per model call, but frequently retries, sends huge amounts of context and escalates many cases. Agent B uses a more expensive model for difficult steps, but completes more workflows correctly on the first attempt. The cheaper model does not necessarily produce the cheaper system.

A practical production cost view includes model usage, retrieval and storage, paid tools and search, infrastructure, monitoring, human review, failed runs, retries, engineering support and the cost of incorrect actions.

We covered the broader budgeting side in our guide to AI Agent Development Cost. The important production shift is this:

Do not optimise the cheapest individual model call. Optimise the cost of a correct completed workflow.

9. Changes to prompts, tools and models need release discipline

A prototype changes constantly. Someone edits the prompt. Someone swaps the model. Someone adds a new tool. Someone changes a document. The team tests it and continues.

That becomes risky once the agent is carrying real work. A production change can improve one set of cases and quietly damage another.

That means AI systems need release discipline. Not necessarily heavyweight process. Just enough control to know:

• What changed.
• Why it changed.
• Which evaluations passed.
• Which model and prompt version are running.
• Whether tool behaviour changed.
• Whether the change increased cost or latency.
• How to roll back.

This is normal software delivery applied to a system whose behaviour is partly probabilistic. The principle is simple. If an agent can affect the business, changing the agent is a production change.

10. Governance becomes part of architecture

For many teams, governance arrives late. The agent works. The demo is successful. Then security, legal or procurement asks where the data is stored, which providers process it, what is logged, who can see the traces, whether a user can tell they are interacting with AI, what happens when a person challenges an automated result, and who approved the system.

These are not paperwork questions. Many of them change the architecture.

For organisations operating in Europe, this matters more now. Certain transparency obligations under Article 50 of the EU AI Act started applying on 2 August 2026.⁴ The specific obligations depend on the system and the role the organisation plays, so this does not mean every AI agent has the same compliance requirements.

It does mean that transparency, human oversight, logging and system purpose should be discussed before launch rather than added as a paragraph in a policy document afterwards.

NIST takes a similar lifecycle view in its AI Risk Management Framework and its Generative AI Profile.⁵ Risk management is not treated as something that begins after deployment. It is part of design, development, evaluation and operation.

The practical lesson is straightforward. If governance can change how the system must work, it belongs in the engineering conversation.

A simple example: support agent prototype versus production

Consider the same customer support use case at two stages.

That is why the production system costs more. It is also why it can be trusted with real work.

How do you know an AI agent is ready for production?

There is no single certification that answers this for every use case. A useful readiness review is more practical. Before launch, the team should be able to answer these questions clearly.

Workflow

1. What starts the agent?
2. What completes the workflow?
3. What is explicitly outside its responsibility?

Data

4. Which data sources can it use?
5. Which sources are authoritative?
6. How are user permissions preserved?

Actions

7. Which tools can it call?
8. Which actions can it perform automatically?
9. Which actions require approval?

Evaluation

10. What does good performance mean?
11. Which test cases represent real work?
12. What would block a release?

Failure

13. What happens when a system is unavailable?
14. What happens when the agent is uncertain?
15. How is work handed to a person?

Monitoring

16. Which quality and operational signals are watched?
17. Who investigates a failure?
18. How are recurring problems turned into improvements?

Governance

19. Where is data stored and processed?
20. Which providers and subprocessors are involved?
21. What logging and transparency are required?

Ownership

22. Who owns the system after launch?

That last question is often missed. It should not be.

Production starts after launch

The first production release is not the finish line. Real users will find situations the project team did not predict. Policies will change. Data will change. Integrations will change. Models will change. Costs will change.

Some cases that looked important during development will barely appear. Other cases will appear constantly.

That is why an AI agent needs an owner after launch. Someone has to review failures. Someone has to maintain evaluation cases. Someone has to decide whether an escalation should become automation. Someone has to approve changes. Someone has to understand both the application and the business workflow.

This is also where AI work starts to overlap with managed platform engineering. If the agent becomes part of a business critical application, it should be operated with the same discipline as the rest of that platform. Our Managed Platform Engineering and Operations work is built around that long term ownership model.

When should you not put an agent into production?

Not every useful prototype deserves a production build. Sometimes the workflow is too rare. Sometimes the source data is too poor. Sometimes a normal software rule can solve the problem more reliably. Sometimes the cost of a mistake is too high for the available controls. Sometimes the organisation is not ready to maintain the system. Sometimes the process itself needs fixing before automation makes sense.

A prototype can still be successful if it reveals that. The goal is not to deploy an agent. The goal is to improve a real piece of work. If a simpler system does that better, build the simpler system.

How we approach production AI at Redevon IT

We start with the workflow, not the model. We want to understand:

• What should change for the business?
• Which systems and data are involved?
• Which actions can the agent take?
• Where does a person need to remain in control?
• How will the team measure whether the agent is doing a good job?
• Who owns it after launch?

From there, the technical design becomes much clearer. The model matters. So do the prompt, tools and retrieval. But the production work is everything around them: integrations, permissions, evaluation, approval, monitoring, failure handling, governance and operations. That is the difference between an AI demo and an AI system.

You can see the broader engineering approach on our AI Agent Development page. For organisations in Ireland, our Ireland engineering page covers procurement, data location and AI governance in more detail. For UK organisations, our UK engineering page explains the same delivery model in the UK market context.

The question to ask before production

Before approving an AI agent for production, ask one question:

If this system makes a mistake at 10:30 on a Tuesday morning, do we know what happens next?

If the answer is clear, you probably have the beginnings of a production system. If the answer is we would need to look into that, then there is still engineering work to do.

The prototype proved the model could help. Production is where you prove the organisation can rely on it.

Frequently asked questions

Ready to move an agent beyond the prototype?

If you have a prototype or a workflow that looks promising, the next step is to define what production actually requires.

Tell us what the agent needs to access, what it needs to do and which decisions should remain with a person. We will tell you what needs to be designed before it can be trusted with real work.

Discuss an AI Agent ProjectDiscuss an AI Agent Project

Sources and further reading

1. OpenAI, a practical guide to building with GPT 5. OpenAI recommends shifting focus toward reliability, evaluation and optimisation once the workflow works from beginning to end: cdn.openai.com
2. OpenAI, Inside our in house data agent. The article describes curated evaluations used continuously to catch regressions and support safer iteration: openai.com
3. OpenAI, Running Codex safely at OpenAI. The article describes technical boundaries, approval for higher risk actions and telemetry for agent activity: openai.com
4. European Commission, Guidelines on transparency obligations for providers and deployers of AI systems. Article 50 transparency obligations apply from 2 August 2026 for systems covered by those provisions: digital-strategy.ec.europa.eu
5. NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile: nist.gov