AI customer service agent with controlled actions.
An agent that resolves routine customer requests — verifying the customer, retrieving order and policy context, preparing the change and stopping for approval when the rules require it.
One connected AI system for customer service.
The client’s service team was handling routine order, delivery and returns requests across multiple systems. Agents had to move between customer records, order data, carrier information and policy documents before they could answer a customer or make a change.
Metabytes designed and built an AI customer service agent that brings that context together, understands the request, retrieves the information needed, applies the relevant policy and either completes the action or routes it for approval.
Not simply faster responses. Less manual work around every request — with people kept in control of exceptions, sensitive actions and higher-risk decisions.
Fragmented handling
- Customer request
- Helpdesk
- CRM
- Order system
- Policy / carrier
- Supervisor
Connected agent workflow
- Request
- Understand
- Retrieve context
- Check policy
- Act / ApprovalHUMAN
- Respond
One delivery change became a seven-step manual journey.
A routine customer request forced agents to collect context from separate systems, interpret policy manually, wait for approval and re-enter the same information before they could respond.
- 01Identify customerCRMAgent searches for the customer record and confirms the account details needed for the request.Manual search
- 02Find orderORDER MANAGEMENTOrder, fulfilment status and current delivery details sit in a separate system.Context switches again
- 03Check policyKNOWLEDGE / POLICYThe agent reads the policy to work out whether the delivery can still change and which conditions apply.Manual interpretation
- Get approvalSUPERVISORRequests outside the normal rules stop while a supervisor reviews the exception.Waiting
- 05Update the systemsORDER SYSTEMCARRIERInformation already gathered earlier in the journey is entered again.Re-keying
The agent was acting as the integration layer.
The systems held the information and actions needed to resolve the request, but the employee had to connect them by hand. That made routine service work slower, less consistent and hard to scale.
AGENTPolicy docsCarrier
AGENTPolicy docsCarrier
Automate the routine. Keep control of the exceptions.
The goal was not to automate every decision. It was to remove unnecessary manual work from routine service requests while keeping approval, policy and audit controls wherever the operational risk remained higher.
Routine tasks needed less searching, less switching and less repeated handling.
- One connected viewCustomer, order and policy information available together, not assembled across separate tools.
- End-to-end handlingStandard requests move from intent to action in one workflow without unnecessary handoffs.
- Consistent answersResponses come from approved operational and knowledge sources, not individual interpretation.
- Less repeated workThe same context is not found and entered again in downstream steps.
One workflow. Clear boundaries.
Coordinate routine work automatically, then slow down deliberately where judgement, approvals or governed actions are required.
- Request
- Retrieve context
- Check rules
- Act automaticallyROUTINE
- Pause for approvalIF NEEDED
- Log actionAUDIT
- Respond
Clear operating boundaries wherever risk, policy or financial exposure stayed higher.
- Human approval where it mattersRequests outside the normal rule set still pause for review.
- Policy and refund limitsRules on refunds, exceptions and post-dispatch changes stay controlled.
- Full auditabilityEvery action, approval and system change is visible and traceable.
- Governed permissionsThe agent can only perform actions that are explicitly allowed.
One agent connecting the service workflow.
Metabytes built the agent around the helpdesk and operational systems the team already used. Instead of replacing them, the agent coordinates them, bringing customer context, order data, delivery information and policy into one decision flow.
Routine requests move from understanding to action automatically. Requests outside approved rules pause for human review, with the full context already assembled for the person deciding.
Context first. Rules second. Action only when allowed.
The agent does not answer from the model alone. It gathers the operational context first, checks the policy and approval rules, then decides whether it can complete the action or needs to stop for a person.
- UNDERSTANDTurn the request into a clear taskThe agent identifies what the customer is asking for and extracts what it needs to continue: the order, the requested change and the relevant customer details.INTENTENTITIES
- RETRIEVEAssemble the operating contextCustomer, order, delivery and policy information is retrieved from the systems and approved sources the request needs.CUSTOMERORDERDELIVERYPOLICY
- DECIDEApply policy before taking actionThe agent checks the rules, thresholds and conditions that decide what happens next. Routine requests continue. Exceptions are routed for approval.RULESLIMITSAPPROVALS
- ACTComplete the change or hand over with contextApproved actions go to the relevant operational tools. If a person needs to decide, they receive the customer, order, policy and proposed action already assembled.ACTIONESCALATION
A modular production architecture.
The agent was built as a set of independent layers rather than one tightly coupled application. Models, knowledge sources, tools and policy controls can evolve independently while the orchestration layer keeps the service workflow consistent.
- 01UnderstandInterpret the request and extract the customer, order and requested action.intent · entities
- 02PlanWork out which context, policies and tools the request needs.state · task plan
- 03RetrieveGather customer, order and policy information from approved sources.grounded context
- 04DecideApply policy, approval thresholds and permissions before choosing an action.rules · approvals
- 05ActCall the approved tool or route the request to a person.tool call · handoff
Broad context in. Narrow actions out.
To resolve a request properly, the agent needed the context systems that explain the customer, order and policy situation. When it came to taking action, access stayed deliberately narrow: the agent could only trigger approved operations in the systems where changes happen.
That separation let the workflow be context-rich without unrestricted operational access, improving speed while keeping permissions, approvals and risk boundaries intact.
Without broad context, the agent could not decide accurately. Without narrow write permissions, the automation would carry more risk than the business could accept. The integration model solved both at once.
- Helpdesk stayed the entry pointThe team kept working in the environment they already used.
- Core systems stayed the source of truthThe agent coordinated them rather than replacing them.
- Actions were constrainedOnly approved operations were exposed to the workflow.
- Exceptions stayed governedRequests outside policy or threshold limits were routed for approval.
Automation with clear boundaries.
The agent was not given open-ended authority. Before any operational action, the workflow checked the request against policy, permissions, confidence and approval thresholds. Routine requests continued automatically. Higher-risk or uncertain cases paused for a person.
Automation could increase without weakening accountability. The same control model decided what the agent could read, what it could change, when it had to stop and what needed to be recorded.
- Policy before actionThe agent checks the relevant operational rule before it is allowed to make a change.POLICY GATE
- Permissions stay scopedThe workflow can only call the actions and systems explicitly made available to it.SCOPED ACCESS
- Uncertainty stops automationLow-confidence or ambiguous requests do not continue as if the answer were certain.CONFIDENCE CHECK
- People stay in the loopHigher-risk requests and exceptions reach a person with the relevant context already assembled.HUMAN REVIEW
- Create its own permissions
- Bypass an approval rule
- Raise its own refund threshold
- Invent a tool action
- Silently ignore a policy stop
From service workflow to production system.
The project was built in stages so the automation reflected the real service operation before any production actions were exposed. Each phase added a layer of certainty, from request types and policies through to evaluation, controlled rollout and ongoing monitoring.
Understand the service operation.
Metabytes mapped the request types, systems, handoffs, policies and approval points involved in day-to-day customer-service work.
- Reviewed common request types
- Mapped the existing agent workflow
- Identified source systems
- Documented policy and exception rules
- Found where work slowed or stopped
- Set the scope of the first release
Follow one request through the workflow.
This walkthrough follows a customer asking to redirect an order that has already been dispatched. Move through the request to see what the agent knows at each stage, which system it uses, where policy changes the route and how human approval comes in before the operational update is completed.
Request arrives
A customer asks to redirect a dispatched order to a new address. The message enters through the helpdesk, and the agent first needs to understand the requested action before it can look up the customer or order.
- request.receivedhelpdesk · chat
- request.classifieddelivery_change
One workflow, with context, action and control connected.
Before the redesign, resolving a request meant moving between systems, re-checking policy and relying on manual hand-offs to keep actions controlled. The new workflow brought those steps together, so the agent retrieves the right context, applies the right rule and takes the next approved action in one connected flow.
That changed more than speed. Routine requests move end to end, governed exceptions still pause for a person and every action stays visible, reviewable and traceable.
- Context scattered across systems
- Policy checked separately
- Manual re-entry between systems
- Approvals depend on hand-offs
- Actions hard to trace
- Context assembled in one workflow
- Policy applied inside the flow
- Approved actions taken in-system
- Governed exceptions pause automatically
- Decisions and outcomes recorded
The workflow did not remove control. It moved control into the operating path.
What mattered most in production.
The hardest parts of the project were not about making a model respond. They were about turning service policy into explicit rules, limiting what the agent could do, deciding where automation should stop and proving those behaviours stayed consistent as the system changed.
The result was a system designed around operational reliability rather than model novelty.
Clear policy mattered more than clever prompting.
The model could only make reliable decisions when the business rules were explicit enough to apply consistently. Ambiguous policy produced ambiguous automation.
Policy rules were separated from model reasoning and made part of the workflow. Approval thresholds, post-dispatch rules and exception routes became explicit control points, not instructions hidden in prompts.
Smaller permissions made the agent easier to trust.
Broad system access would have made the agent harder to test, audit and constrain. The useful work could be done through a much smaller set of specific actions.
The agent received narrowly scoped tools, such as order lookup, carrier redirect, CRM note and approval routing, instead of access to whole applications.
Knowing when not to act was just as important.
An agent can fail by taking the wrong action, and by acting when it should have stopped. Low confidence, policy exceptions and higher-risk cases had to be first-class test scenarios.
Evaluation covered escalation, approval and refusal behaviour as well as successful completion. Regression checks included the moments where automation should pause.
Production behaviour needed to stay observable.
Once the agent could retrieve data and take actions, debugging single responses was not enough. The team needed the full request path: tool calls, approvals and outcomes.
Tracing, audit records, alerts and regression checks became part of the production operating model, not optional engineering extras.
Production AI is mostly about the system around the model.
Model quality matters, but it was only one part of the solution. The result depended equally on policy clarity, controlled tool access, tested stop conditions, human approval and the ability to trace what happened after every request.
One foundation, several next moves.
The first workflow established the parts that are hardest to build well: connected context, scoped tools, explicit policy controls, human approval and traceable operation. From there, the same foundation can extend into adjacent service journeys without starting again from zero.
Some expansions reuse the same systems and mainly need new policy logic. Others add a channel or change the role the agent plays.
Returns & refunds
The workflow already has the customer, order and policy foundations needed to handle many returns and refund requests.
Reuse the operating layer. Add only what the next workflow needs.
New service journeys can reuse the same context, governance, tooling and operational controls rather than recreating them independently.
Explore other projects.
Questions about AI customer service agents
Bring us the workflow.
Tell us which customer requests take the most handling time. We can map the systems, rules and approvals involved and show where an agent would fit.
Where could an agent take on service work?
Bring us the request types, systems, policies and approval rules. We will map where an agent can resolve work end to end, where it should hand over to people and how it will be evaluated before you commit to production.