A prototype agent can answer questions, call an API, or automate a workflow in an afternoon. A production-ready AI agent must do those things predictably, safely, and at an acceptable cost—under real traffic, incomplete data, tool failures, adversarial prompts, and changing business rules.
For Indian startups, this usually means designing for constrained budgets, multilingual users, regional latency, privacy obligations, and integrations with systems that were not built for AI. The right goal is not maximum autonomy. It is bounded autonomy: give the agent enough freedom to complete useful work, while making its decisions inspectable and its high-impact actions controllable.
Start with a bounded workflow
Before selecting a model or framework, define the job precisely. An agent is justified when a workflow involves variable inputs, multiple steps, tool use, or decisions that cannot be expressed cleanly as fixed rules. If the process is deterministic, a conventional service or state machine will usually be cheaper and easier to operate.
Write down:
- The user or business outcome, not just the conversation you want to create.
- The tools the agent may call and the data each tool can access.
- Actions that are read-only, reversible, or irreversible.
- Maximum execution time, model calls, tool calls, and spend per task.
- Conditions under which the agent must ask a question, stop, or escalate.
- Success metrics such as task completion, groundedness, resolution time, and cost per successful task.
This framing is especially important for voice and multilingual products. A customer-service agent may need speech recognition, language detection, retrieval, and escalation in one loop; the practical design principles are covered in this voice-agent architecture and deployment guide.
Choose an architecture that can be inspected
Use a workflow graph or explicit state machine rather than an unconstrained loop. A typical production flow is:
1. Authenticate the request and classify intent.
2. Load the minimum required user and session context.
3. Decide whether retrieval or a tool call is necessary.
4. Validate tool arguments before execution.
5. Execute the tool with timeouts, retries, and idempotency controls.
6. Check the result and either continue, ask for clarification, or escalate.
7. Produce a structured response and record a trace.
Frameworks such as LangGraph, Temporal, or a small internal orchestration layer can represent this flow. The framework matters less than the properties: every transition should be visible, state should be durable, and loops should have explicit exit conditions.
Persist state in a database suited to the workload. PostgreSQL is often a practical default for users, tasks, permissions, and audit records; Redis can support short-lived locks, queues, and caching. Store references to large tool outputs rather than repeatedly placing entire payloads into the model context. Keep conversation history, business state, and audit logs separate so that retention and deletion policies remain manageable.
For multi-agent or distributed workloads, define ownership and communication contracts before adding more agents. This guide to building distributed systems with AI agents is useful when tasks span queues, services, or independent workers.
Design tools as secure APIs
Treat every tool as an untrusted boundary. Give it a narrow purpose, a strict JSON Schema or Pydantic contract, and the least privilege required for the task.
Good tool design includes:
- Typed inputs: Enumerations, length limits, formats, and required fields.
- Typed outputs: Stable response objects with explicit error states.
- Timeouts and retries: Retry only transient failures, with exponential backoff.
- Idempotency: Prevent duplicate payments, tickets, messages, or bookings.
- Authorization: Recheck the user’s permissions inside the tool, not only in the prompt.
- Auditability: Record who initiated the action, what changed, and which approval permitted it.
Never allow a model to directly construct unrestricted SQL, shell commands, or outbound requests. If code execution is necessary, use a disposable sandbox with network restrictions, resource limits, and no production credentials. For irreversible actions, implement human approval as a first-class state—not as an instruction buried in a system prompt.
Build retrieval for evidence, not decoration
RAG is valuable only when it retrieves the right evidence and the agent uses that evidence correctly. Start with document ownership, freshness, access permissions, and source attribution. Chunk documents by meaning, preserve headings and tables where possible, and attach metadata such as language, department, effective date, and tenant.
A practical retrieval stack may combine:
- Dense vector search for semantic similarity.
- BM25 or another lexical search method for names, IDs, codes, and exact phrases.
- Metadata filters for tenant, geography, language, and document status.
- Reranking for the most relevant results.
- Parent-document expansion when a small matched passage lacks context.
Ask the model to cite source identifiers internally or in the user-facing answer, and define an explicit “insufficient evidence” response. Test retrieval separately from generation: if the correct passage is absent from the candidate set, a better prompt will not solve the problem.
For Indian products, measure retrieval by language and script. Devanagari, Tamil, Bengali, transliterated Hindi, Hinglish, and code-switched queries can behave very differently. Work on low-resource Indic NLP can inform language detection, transliteration, evaluation data, and model selection.
Evaluate the complete task
A production evaluation suite should combine deterministic tests, curated scenarios, and sampled real traffic. Build a golden dataset from successful cases, known failures, ambiguous requests, tool outages, prompt-injection attempts, and multilingual examples. Include expected tool calls and acceptable answer variants where exact text matching is inappropriate.
Track metrics at several levels:
- Task success: Did the user’s intended outcome occur?
- Tool correctness: Were the right tools called with valid arguments?
- Retrieval quality: Did the evidence contain the answer and respect permissions?
- Groundedness: Were claims supported by available evidence?
- Safety: Did the agent avoid unauthorised disclosure or action?
- Operations: Latency, failure rate, token usage, and cost per completed task.
Use an LLM judge for scalable review only after calibrating it against human labels. Keep deterministic checks for schemas, permissions, citations, prohibited outputs, and business invariants. Run regression tests on every prompt, model, retrieval, and tool change; agent behaviour can change even when application code does not.
Add observability before launch
Capture a trace for each run: model and version, prompt-template version, retrieved document IDs, tool arguments and results, retries, state transitions, latency, token counts, and final outcome. Redact or tokenize personal data before sending traces to third-party observability platforms. Set retention by purpose rather than keeping everything indefinitely.
Create dashboards for:
- Success and escalation rates by workflow, language, and customer segment.
- Tool errors, timeout rates, and retry volume.
- p50, p95, and p99 latency, including time to first token.
- Cost per request and cost per successful task.
- Prompt-injection, policy, and data-access violations.
Use feature flags and canary releases for model or prompt changes. A rollback should restore the previous model, prompt, retrieval index, and tool policy—not merely the application container.
Control security, privacy, and autonomy
Threat-model the system before exposing it to customers. Prompt injection can arrive through user text, retrieved documents, emails, web pages, or tool output. Treat all of those as data, not instructions. Separate system policy from retrieved content, restrict tool permissions, validate outputs, and add egress controls for sensitive environments.
For healthcare, legal, finance, and government use cases, define data residency, access logging, consent, retention, deletion, and incident-response requirements early. A private deployment may be appropriate where sensitive documents cannot leave the organisation; compare that approach with this private AI chatbot guide for lawyers. Human review should be mandatory for financial transfers, legal commitments, medical decisions, bulk communications, account changes, and other high-impact actions.
Optimise cost and latency deliberately
Set a budget per workflow and enforce it in code. Use a small model for classification, extraction, routing, and simple responses; reserve larger models for ambiguous reasoning. Reduce context with summarisation and targeted retrieval, cache stable instructions, batch offline work, and stream responses when it improves perceived latency.
Do not optimise token cost at the expense of failure cost. A cheap model that misroutes a support request or duplicates an operational action may be far more expensive than a larger model used selectively. Compare models on cost per successful task, not price per million tokens alone. If self-hosting is viable, benchmark vLLM or another serving stack against managed APIs using your own concurrency, language, and latency requirements. See how to deploy Llama 3 agents for a model-serving path.
A practical launch checklist
Before production, verify that you can answer “yes” to these questions:
- Is the workflow bounded with a maximum number of steps and model calls?
- Can every tool call be authenticated, validated, retried, and audited?
- Does the agent stop safely when evidence, permissions, or tools are missing?
- Are multilingual and adversarial cases in the regression suite?
- Can operators inspect a complete trace without exposing unnecessary PII?
- Are high-impact actions gated by approval?
- Can you roll back prompts, models, indexes, and policies independently?
- Do dashboards show success, latency, failure, escalation, and cost?
Launch with a narrow workflow, a small cohort, and clear escalation paths. Expand autonomy only after production evidence shows that the agent is reliable for the specific task—not because a demo appears convincing.