AI agents that answer, sell, and support, for a two-sided marketplace.
The marketplace had momentum, but its support queue was absorbing the upside. Buyers needed quick answers on orders, returns, and product fit. Sellers needed clarity on policies, payouts, and held orders. Most tickets were routine, but the volume kept pulling the operations team away from the exceptions that actually needed human judgment.
Keep the CRM. Keep the operating model. Add an agent layer in front of it that could answer common questions, complete approved actions, and escalate sensitive cases with a clear audit trail.
What shipped
Start where the buyer already is
The buyer agent sits inside the same chat surface shoppers already used for support. A shopper can ask "where's my order," "can I return this," or "reorder my last one." The agent checks the CRM, answers in plain language, and completes approved next steps without forcing the shopper into another workflow. Support became less of a waiting room and more of a guided purchase path.
Give sellers answers without exposing the marketplace
Sellers got a separate agent in their operations dashboard. It can explain why an order was held, what policy applies, when a settlement window closes, and which disputes still need attention. The important part is the boundary: the agent only receives context for the seller asking the question, so convenience does not come at the expense of data isolation.
Let the old system stay boring
The legacy CRM stayed exactly where it was. We added a narrow bridge between the agents and the CRM, with validation on every read and write. Routine actions could move quickly; unusual or high-value actions were routed to a human reviewer. The result was not a new platform, it was a controlled front door to the platform they already trusted.
What it looked like in action
Representative mockup using anonymized sample data. The interaction patterns reflect the production flows; names, amounts, IDs, and dates are illustrative.
Business outcomes
Technical work demonstrated
The systems and controls behind the story above.
Multi-agent orchestration on managed clusters
Two isolated agent clusters, scaled independently, with no shared blast radius between buyer-side and seller-side workloads.
Permission-scoped retrieval (RAG)
The seller agent retrieves from an internal vector store with row-level scoping, so an agent literally cannot see another seller's context.
Event-driven tool calling via message bus
Agents call each other's tools through an event bus, decoupling latency and letting long-running actions complete without blocking the chat.
Structured-output validation with strict schemas
Every action, place_order, issue_refund, update_status, is gated by a strict schema. Malformed agent outputs are dropped before they touch the legacy CRM.
Incremental rollout with custom middleware
Microservices wrap the legacy CRM, sync data both ways, and let the team introduce agent workflows without replacing the underlying system.
Region-aware inference and retrieval
LLM calls, retrieval, and operational logs were designed around regional data-handling requirements and least-privilege access.
Architecture
Two agents, two jobs
A buyer agent that runs in the shopper's chat and answers product and order questions. A seller agent that runs in the seller dashboard, scoped strictly to that seller's data, answering policy, payout, and order questions from internal knowledge.
A safe bridge to the existing system
A small set of resilient services sits between the agents and the legacy CRM, translating, validating, and rate-limiting every read and write so the old system never sees a malformed call.
Every action is checked before it happens
Order placements, refunds, and status changes are all gated by a strict output check. If an agent ever produces something that doesn't match the expected shape (wrong field, missing approval, suspicious value), the action is blocked before it leaves the agent layer.
Least-privilege access
Agents receive only the data needed for the current user, role, and task. Seller context is scoped before retrieval begins.
Sensitive-data minimisation
The system reduces unnecessary personal or payment-adjacent details before model calls and keeps operational logs focused on the decision trail.
Answer and action checks
Responses and tool calls pass through validation rules so off-policy commitments, missing fields, and unusual actions can be blocked or escalated.
Human review where it matters
High-risk actions and edge cases pause the autonomous flow and wait for an authorised reviewer before the CRM is updated.
Where this proof applies
This case study supports the solution and service pages below because the same workflow, controls, and handoff model are visible in the implementation.