---
title: "Generative AI and agents"
description: "Retrieval augmented generation, agents with real tool use, and the evaluation, guardrails and monitoring that let a legal, security or compliance team approve them."
url: https://www.expandware.com/services/ai/generative-ai-and-agents/
section: "Services"
topics: ["AI", "Anthropic Claude", "OpenAI", "Google Gemini", "Llama"]
publisher: "Expandware Private Limited"
---

# Generative AI and agents

Retrieval augmented generation, agents with real tool use, and the evaluation, guardrails and monitoring that let a legal, security or compliance team approve them.

Production AI systems, not demos.

Most AI initiatives die between the prototype and production. We build the part that survives: retrieval pipelines on private infrastructure, agents that act through your own systems, and the guardrails, monitoring and validation that give your reviewers something concrete to approve.

Where it usually starts:
- An AI prototype demos well, but nobody will sign off on putting it in front of customers.
- Staff paste company data into public chat tools because there is no approved alternative.
- Answers have to come from your own documents, with the same permissions the documents have.
- A workflow needs an assistant that takes actions, not one that only talks.

What is included:
- Retrieval augmented generation: Search over your documents and data, with permissions that follow the user.
- Agents and tool use: Assistants that call your systems through scoped, logged tools.
- Model selection and hosting: Commercial APIs, or open-weight models on your own infrastructure.
- Evaluation: Test sets built before launch and run on every change.
- Guardrails: Prompt injection defense, output validation and limits on what the model may do.
- Observability: Tracing, cost tracking and quality monitoring in production.

Where it sits: This service builds most of the serving path in the AI architecture: ingestion from your documents and business systems into a vector index, the agent runtime that acts on them, and the private model it calls, each behind the guardrails other services define.

Decisions to settle early:
- Retrieval or fine-tuning. Retrieval keeps answers current and citable without training a model; fine-tuning changes style or narrow behavior. Most business assistants need retrieval first.
- Assistant or agent. An assistant answers; an agent acts. Acting brings value and risk, so we decide which actions an agent may take on its own and which need a person.
- Where the model runs. A commercial API, a cloud-hosted open model or your own hardware each trade quality, control and cost. We test the candidates on your evaluation set.

How the work runs: Ground, Retrieval over your own content. Build, Agents, tool use and prompt design. Guard, Injection defense and output validation. Measure, Evaluation on every change.

How it is bought:
- A fixed-fee assessment: We test a candidate use case against your own content and systems, measure a baseline, and agree acceptance thresholds with the people who will approve it. You receive the findings and a fixed price for building it.
- A fixed-price build: Retrieval, agent tools, guardrails, the evaluation set and production deployment for the use case in scope, built to the agreed thresholds at a fixed price.
- Running it afterwards: Once live, the system can be run by your team with monitoring and runbooks, or by us monthly, covering evaluations on every change, model updates and quality incidents.

Worked example, an assistant nobody would sign off. Say a legal operations team has a prototype that answers questions from contracts and policies. It demonstrates well, but the risk committee will not approve it, because nobody can say how often it is wrong or what it does with documents a user should not see.
- Specify: We agree with the committee what the assistant may answer, when it must decline, and the accuracy it must reach on a test set before launch.
- Ground: Retrieval is rebuilt on the document system's own permissions, so a user is only ever answered from documents they could already open.
- Evaluate: A test set drawn from real questions is scored on every change to the model, prompts or retrieval, and the results go to the committee.
- Operate: The assistant goes live with tracing, cost tracking and a way for users to flag a wrong answer, which feeds the next evaluation.
At the end, the committee approves a system whose behavior is measured rather than demonstrated, and every answer can be traced to the documents it came from. (An illustration, not a client account.)

What you have at the end:
- Use case specification with acceptance thresholds: What the system must do, what it must never do, and the measured quality it needs before it goes live.
- Evaluation set and results: Representative questions and tasks with expected answers, run against every version, with the scores.
- Deployed application with guardrails: The application in your environment, with input checks, output validation and limits on the tools it may call.
- Model and prompt version history: Every model, prompt and retrieval change on record, so a change in behavior can be traced to its cause.
- Monitoring dashboards and runbooks: Quality, latency, cost and failure dashboards, with procedures for the incidents an AI system can have.

Standards and platforms worked with: Anthropic Claude, OpenAI, Google Gemini, Llama, Mistral, Model Context Protocol, OWASP Top 10 for LLM Applications, vLLM.

Where it goes wrong, and what we design out:
- Launching on a demonstration. A prototype that impresses in a meeting can fail on real questions. Nothing launches without passing an evaluation set built from actual use.
- Permissions lost in retrieval. An index that ignores document permissions leaks information to the wrong people. Retrieval enforces the same access the source system does.
- Tools without limits. An agent with broad access can do broad damage. Every tool is scoped, logged, and confirmed by a person where it changes data or spends money.

What it changes:
- Controlled access to knowledge. Retrieval and tool permissions follow source authority, user identity and data boundaries, so the model cannot simply see everything.
- Measured usefulness. Evaluation sets, acceptance thresholds and human review paths turn an impression into a release decision a product and risk team can own.
- Operable model behavior. Tracing, versioning, cost controls and fallback behavior keep the system diagnosable after the demo ends.

How you will know it is working:
- Reviewers approve releases from evaluation results, not from demonstrations.
- Answers cite the documents they came from, and users can check them.
- A change to a prompt or model shows its effect on quality before release.
- Running costs per answer are known and tracked over time.

Who you work with:
- AI engineer. Designs the retrieval, agent tools and prompts, and owns the evaluation set.
- Software engineer. Integrates the assistant with your systems, permissions and user interface.
- Evaluation and safety reviewer. Tests for wrong answers, leakage and prompt injection before each release.

What we need from you:
- Access to the documents and systems the assistant should use.
- Real questions or tasks from the people who would use it.
- A reviewer or committee who will approve the release.
- Your rules on what data may leave your environment.

Common questions:

Q: Can sensitive data remain inside our environment?
A: Yes. We design for the boundary you need: private retrieval infrastructure, controlled integrations, least privilege access, and self-hosted models where data may not reach a third party.

Q: How do you reduce hallucinations and unsafe tool use?
A: We combine grounded retrieval, constrained tool permissions, output validation, adversarial testing and monitoring. No single technique is treated as a complete guardrail.

Q: How do we know whether an AI feature is getting better or worse?
A: Through an evaluation set built before the feature ships and run on every change. Without one you are relying on whoever tried it most recently, which is why teams end up unable to say whether last month's prompt edit helped.

Q: What does this cost to run once it is live?
A: Inference cost follows usage, so the variable is how much context each request carries and how often retrieval runs. We model that during design, because the cheapest system to build is often not the cheapest to operate.

Q: What is retrieval augmented generation?
A: A design in which the model answers from documents retrieved for each question, rather than from what it learned in training. It keeps answers grounded in your current content, lets them cite their sources, and means the model never has to be trained on your data.

Q: Should we use a commercial model API or host an open-weight model?
A: It depends on the data, the volume and the quality required. Commercial APIs are usually the strongest and the quickest to start with; open-weight models on your own infrastructure give more control over data and cost at steady volume. We test the candidates on your evaluation set before choosing.

Q: What is the Model Context Protocol?
A: An open protocol for connecting AI assistants to tools and data sources through a standard interface. We use it where it fits, because one set of scoped, logged tools can then serve several assistants, and the permissions of each tool are explicit.

Q: How do you stop an agent taking an action it should not?
A: Each tool an agent can call is scoped to the narrowest permission it needs, actions that change data or spend money require confirmation, and every call is logged. Instructions that arrive inside retrieved content are treated as data, never as commands, which is the core of prompt injection defense.

Often paired with: Data integration and analytics, AI governance and security, MLOps and model operations.

---

Canonical page: https://www.expandware.com/services/ai/generative-ai-and-agents/
Site index for machines: https://www.expandware.com/llms.txt
Full site text: https://www.expandware.com/llms-full.txt

Expandware Private Limited. Inquiries: solutions@expandware.com, +92 (333) 32 11011.