The middle path: one agent, one read-only door, one approved data source. The fix is engineering, not prompt-writing. Retrieval over approved knowledge, a few tightly scoped tools, and controls that make every answer traceable.

What we built: five agents, one platform

We built on Haystack, an open-source orchestration framework, for one reason: it is modular. Models, retrievers, tools and evaluators are separate components, each swapped, tested and governed on its own. When a better model ships next quarter, you change one component, not the product.

On that base we built five working agents, each testing a pattern buyers ask us about.

Document assistant. Answers from a document set and cites the passage it used. The pattern behind policy, contract and knowledge search.

Visual retrieval pipeline. Reasons over diagrams, scans and images, where the answer is not in plain text.

Code repository explainer. Uses the Model Context Protocol (MCP) to give an agent structured, tool-based access to a codebase. Any system with an MCP server connects the same way.

Research assistant. Answers only from websites the user selects, so research stays focused and auditable.

Sales Agent. Guided selling on live product data from a premium footwear retailer.

One orchestration layer, one governance model, five use cases. You don’t need five AI projects and five security reviews.

Every request passes identity, orchestration and a controlled tool layer before it reaches data.

Inside the Sales Agent

This is the agent customers would see, so it carries the strictest rules.

A shopper types: “Do you have the black Wholecut Oxford in UK size 8?” The agent checks stock, quotes the price and, if the size is gone, offers the closest alternatives. Then: “What would I wear with a tuxedo?” It keeps the thread, recommends formal options from the catalog and says why each one fits. That is a sales associate, not a search box.

Three design choices make it safe to put in front of a customer.

Read-only, project-scoped tools. It can look up products. It can’t change a price, place an order or see anything outside its scope.

A validated query service. The model never writes a query against your database. It asks a service, the service validates the request, and only approved facts come back: stock, size, color and price.

Memory within the conversation. Follow-up questions build on earlier answers, the way a good store associate’s would.

Put the control in the service, not the prompt. Prompts can be talked around. A read-only service can’t.

Where else does this pattern work?

E-commerce and retail: guided selling, fit advice and order questions answered from live data.

Financial services: policy and product questions, with every answer traced to its source document.

Logistics: shipment status and exceptions, with no write access to operational systems.

Media: research across archives and rights data, from licensed sources only.

The outcome is the same everywhere: repetitive questions off your team, faster answers at the moment a customer is ready to act, and no new security risk.

What does it take to go from demo to production?

More than the demo. This was a proof of concept. It proved the pattern; it did not prove production. We have not yet benchmarked it under real load, and we would not put it in front of customers until we had.

The proof of concept shows it works. The pilot shows it is safe to run.

Every item on the right gets measured before anyone talks about rollout: answer quality, tool-selection accuracy, query accuracy, latency and cost.

RMgX runs 15+ AI solutions in production. The lesson from every one of them: the model, the data and the engineering get designed together, or the project stalls at the demo. That is how our Data Analytics & AI Solutions team approaches every build.

How to start: one controlled pilot

1. Pick one question. The one your customers or team ask most, where a faster, grounded answer moves revenue or cost.

2. Draw the boundary. Exactly what the agent can read and do, enforced by a service, not a prompt.

3. Build and measure. Agreed targets for accuracy, latency and cost, tested on masked or non-production data.

4. Decide on evidence. Scale it, change it or stop. All three are good outcomes when the numbers make the call.

AI agents are ready for real business work. Most implementations aren’t. The difference is engineering.

Bring us the one question your customers ask most. In a 30-minute use-case review, we’ll tell you whether an agent should answer it, and what a controlled pilot would look like on your data. Book a technical consultation.

Frequently asked questions

Is it safe to connect an AI agent to our production data?

Yes, if the agent never touches it directly. Our agents reach data only through a read-only service that validates every request and returns approved fields. The model can’t change a price, read a customer record or run a query you didn’t allow. Early pilots run on masked or non-production data.

Are we locked into one AI model provider?

No. Haystack treats the language model as one replaceable component. Retrieval, tools and governance stay the same when the model changes, so you can move to a better or cheaper model, or one your compliance team prefers, without rebuilding the product.

What does a pilot need from our side?

One use case, one approved data source and a named owner who can say what a good answer looks like. We build the controlled service, the agent and the evaluation, then hand you the numbers on accuracy, latency and cost so you can decide whether to scale.