Customer operations agent
Live in production
Give the model room to interpret. Make actions reviewable.
A production agent that helps a customer team prepare operational work through conversation, review a concrete proposal, and carry out approved actions. I own the product and technical work end to end, including its continued development around real use.
My role
Product and technical owner
Current state
The agent is live in production and under active development.
Select a stage to explore the diagram.
Prepare
Conversation helps the operator express a request and prepare a concrete proposal. The proposal gives the person something specific to inspect.
Review
A person reviews the proposed work before it proceeds. Understanding a request and authorizing an action are separate responsibilities.
Act
Application code carries out approved work and returns a report. The model's interpretation alone does not authorize the consequential action.
Start with a bounded job
The customer had an existing operational workflow that required people to select the right work, check what was about to happen, and act across business systems. Conversation offered a more direct way to express the request. It also introduced ambiguity into a process with real consequences.
I owned the project end to end: product scope, technical decisions, implementation, and ongoing development, working with coding agents throughout. The first slice centered on an existing, observable task. That gave us a concrete interaction to build and inspect before expanding the agent’s responsibilities.
Separate understanding from authority
The central decision was where to put the boundary between the model and the application. The model helps interpret intent and prepare work. A person reviews the proposed action. Application code controls execution and reports the result.
That separation makes the proposal the useful unit of interaction. An operator can inspect what will happen before approving it, rather than having to infer the agent’s intentions from a conversational answer. The interface has to make that moment clear: what is being proposed, whether it has been approved, and what happened afterward.
The diagram above is deliberately abstract. It explains this division of responsibility without reproducing the customer’s integrations, operating rules, or implementation.
Follow the complete interaction
The work extended beyond getting a model to call the right function. The operator also needed a coherent path through review, action, and the result. A successful backend operation is only part of that experience; the interface still has to show the right state and make the next action understandable.
Verification therefore included the complete interaction in the surface the team actually uses. This exposed assumptions that were easy to miss when examining individual components. Customer feedback also informed subsequent changes to the workflow after deployment.
The broader lesson is that an agent product has several kinds of correctness. Interpreting the request matters. So do the authority to act, the behavior of the application, and the operator’s understanding of the result. Each needs its own design and verification.
Current state
The agent is live in production and actively developed. I continue to own the work as the customer’s needs evolve.