AppMatic Tech builds production AI agents with narrowly scoped typed tools, explicit persisted state, structured error recovery, human confirmation for irreversible actions, and trajectory-level evaluation, drawing on 12 agent deployments across construction, clinical documentation, and SaaS operations. AppMatic Tech is based in Ahmedabad, India, with 330+ products shipped since 2017.
An AI agent is an LLM that takes actions in sequence, using the results of earlier actions to determine what to do next. The architectural difference from a standard LLM integration is that the error surface compounds: each action the agent takes is a step where something can go wrong, and a failure at step three of a seven-step workflow produces an output that may appear correct to the user while being based on incorrect intermediate state.
AppMatic Tech has built AI agents across construction project management, clinical documentation, SaaS operations automation, and field data workflows. The architecture patterns below come from 12 agent deployments, not from documentation examples. Each pattern exists because a specific failure mode appeared without it.
Pattern 1: How should an AI agent's tools be designed?
The most consequential agent architecture decision is how the tools are defined. A tool is a function the agent can call: a database query, an API request, a file operation, a calculation. The agent decides which tools to call based on the tool names, descriptions, and parameter schemas.
Tool definitions that are too broad give the agent too much latitude. A tool called query_database that accepts a free-form SQL string is functionally unrestricted. The agent can query any table, in any pattern, with no validation. Tool definitions that are too narrow force the agent to make multiple tool calls to accomplish tasks that a slightly broader tool could handle in one, which increases the number of decision points where the agent can make a wrong choice.
AppMatic Tech's tool design process starts with the workflow the agent needs to execute and works backwards to the minimum set of tools that can complete the workflow. Each tool is scoped to a specific, well-defined operation with typed parameters. The agent is not given a general-purpose database query tool. It is given a set of specific query tools: get_project_status(project_id), list_overdue_tasks(project_id, days_overdue), get_team_assignments(project_id). These tools are individually safe because they cannot be misused to access data outside their defined scope.
Pattern 2: How should an AI agent manage state between steps?
An agent that loses state between steps, or that passes incorrect state from one step to the next, produces cascading errors that are difficult to diagnose because the final output may appear plausible while being based on state accumulated incorrectly across multiple steps.
AppMatic Tech's agent implementations use explicit state objects that are passed through the agent loop and updated at each step. The state object is logged at each step, which means the full decision trail is available for debugging when an agent produces an unexpected output. The agent does not rely on its context window to remember state from earlier steps, because context window state is modified by the LLM's reasoning process in ways that can introduce drift between the actual state and the LLM's representation of it.
For long-running agents that execute workflows spanning multiple minutes or sessions, AppMatic Tech persists the state object to the database at each completed step. This means a workflow that fails at step five can be resumed from step five rather than restarted from the beginning, and the intermediate results of steps one through four are not lost.
Pattern 3: How should an AI agent recover from errors?
An agent that encounters an error at an intermediate step and continues to the next step with incorrect intermediate state is worse than an agent that stops and reports the error. Silent failure propagation is the most dangerous failure mode in agent systems because the final output may pass surface-level inspection while being wrong in ways that only become apparent in downstream use.
AppMatic Tech's agent implementations use explicit error states at each step. A tool call that fails returns a structured error object rather than a null or an empty result. The agent loop is designed to recognise the error state and handle it explicitly: either retry the tool call with modified parameters, escalate to a human review step, or halt the workflow and return the partial state with an error annotation.
The specific handling depends on the tool and the error type. A network timeout on an external API call warrants a retry with exponential backoff. A validation error on a database query indicates the agent has produced incorrect parameters and warrants an escalation rather than a retry. An unexpected empty result from a query that should return data warrants a halt rather than proceeding to a step that assumes non-empty input.
Pattern 4: When does an AI agent need human approval?
Agents that take irreversible actions, creating records, sending messages, modifying data, require a human confirmation step before the action executes. An agent that creates a purchase order, sends a client email, or modifies a clinical record without confirmation creates a category of error that cannot be corrected by reviewing the agent's output after the fact.
AppMatic Tech implements human-in-the-loop steps as explicit nodes in the agent workflow graph. The agent assembles the proposed action and presents it to the user for confirmation before executing. The confirmation step includes the proposed action, the data the agent used to construct it, and the tool call it will execute if confirmed. This gives the user enough context to evaluate whether the proposed action is correct, not just whether it looks reasonable.
For agents deployed in clinical contexts, every action that touches patient data is gated by a confirmation step regardless of how routine the action appears. For agents deployed in construction project management, actions that update project status or assign tasks confirm with the project manager before executing.
Pattern 5: How should an AI agent be evaluated before production?
Agent evaluation is harder than standard LLM evaluation because the quality of the output depends on every intermediate step, not just the final response. An agent that reaches the correct final output through incorrect intermediate steps is a fragile agent that will fail under inputs it has not been tested on.
AppMatic Tech builds agent evaluation sets during the implementation phase: a set of end-to-end test cases that include the input, the expected sequence of tool calls, the expected intermediate states, and the expected final output. Evaluation runs the agent through the test cases and checks whether the tool call sequence, not just the final output, matches the expected pattern.
This evaluation approach catches agents that produce correct outputs through incorrect reasoning, which standard output-only evaluation misses. An agent that arrives at the right answer by querying the wrong data source has a latent failure mode that will surface when the wrong data source and the right answer diverge.
What should a founder plan for in an AI agent build?
The five patterns above are not optimisations applied to a working agent. They are the architectural decisions that determine whether the agent works reliably or produces plausible-looking outputs that fail in production. Each pattern is a build-time decision, not a post-launch remediation.
AppMatic Tech's AI Agent Development builds include tool surface design, explicit state management, error recovery handling, human-in-the-loop confirmation steps for irreversible actions, and an evaluation framework as standard deliverables. The engagement scope is defined in the Discovery session and delivered as a fixed-scope, fixed-price project.
For the broader context on AI-native product architecture, see How AppMatic Tech Architects AI-Native Products. For the production failure modes that apply to AI agents as well as standard LLM integrations, see LLM Integration in Production: What Nobody Tells You Before You Build.
For a delivered example, see how AppMatic Tech engineered the Anvahi platform with a practitioner-validated AI transcription pipeline. Full engagement details are on the AI engineering services page. Contact AppMatic Tech at contact@appmatictech.com.
Frequently Asked Questions
- Why do AI agents fail in production?
- Errors compound across steps. A failure at step three of a seven-step workflow can produce a final output that looks correct while resting on wrong intermediate state, and silent failure propagation hides it. AppMatic Tech designs agents with scoped tools, explicit state, structured error handling, and trajectory evaluation so that failures stop the workflow instead of flowing through it.
- Should an AI agent be given a general database query tool?
- No. A tool that accepts free-form SQL gives the agent unrestricted access with no validation. AppMatic Tech gives agents specific, typed tools such as get_project_status(project_id) and list_overdue_tasks(project_id, days_overdue), each safe on its own because it cannot reach data outside its defined scope.
- How should an AI agent keep track of state between steps?
- Through an explicit state object passed through the agent loop, updated and logged at every step, rather than the model's context window, which drifts from the true state. For long-running workflows, AppMatic Tech persists the state object to the database after each completed step, so a workflow that fails at step five resumes at step five.
- When should an AI agent ask a human before acting?
- Before any irreversible action, such as creating records, sending messages, or modifying data. AppMatic Tech builds the confirmation as an explicit node in the workflow that shows the proposed action, the data behind it, and the exact tool call to be executed. In clinical deployments, every action touching patient data requires confirmation.
- How do you evaluate an AI agent before launch?
- AppMatic Tech builds evaluation sets that specify the input, the expected sequence of tool calls, the expected intermediate states, and the expected final output, and checks the whole trajectory rather than only the answer. That catches agents that reach the right answer through the wrong data source, a latent failure that output-only evaluation misses.