Aishee Ray Chaudhuri
AIFwd brought AI practitioners together to examine what happens once AI enters production. Four sessions explored agent architecture, context engineering, on-device AI, and evaluation, revealing how much production reliability depends on the engineering surrounding the model.
An AI agent can generate working code in minutes, complete a controlled task, and make a complex workflow look remarkably simple during a demo.
Production introduces a much larger set of variables. The agent enters an established codebase with years of decisions embedded across files and services. Its context grows as the task progresses, and one inaccurate assumption can influence several subsequent steps. On a mobile device, inference begins competing with the application itself for memory and computation. Once real users enter the picture, thousands of interactions start exposing failure modes that were difficult to anticipate during development.
Engineering teams eventually have to answer a more demanding question: how do we build an AI system that continues to perform reliably once the controlled conditions disappear?
This very question shaped AIFwd: Claude Code in Action, hosted by Coditas on August 22, 2026, at its Pune headquarters. The half-day practitioner event brought together engineers, developers, founders, product professionals, AI leaders, and emerging talent to discuss the realities of building and deploying production-ready AI systems.
“Claude isn't the hard part. Production is.”
The event comprised four sessions that approached production from different layers: agent architecture, context, hardware, and evaluation. Together, they formed one argument about what happens after model capability is established. Architecture determines how work is coordinated, context determines what the model can reason over, hardware sets the boundaries of execution, and evaluation reveals where the system needs improvement. Production reliability depends on how deliberately those layers are engineered around the model.
A Practitioner Room Built Around Production Questions
AIFwd focused on implementation experience, engineering decisions, failure points, and lessons from systems that have already encountered real-world constraints. The agenda covered context engineering, AI evaluation, on-device AI, and agent architectures, alongside audience discussions, Q&A, and networking.
Attended by professionals working across product, AI, data, testing, UX, and technical leadership, the event focused on answering questions that appear once AI systems have to operate beyond controlled experiments.
When Does an Agent Loop Need More Structure?
As agent workflows take on more steps, tools, and dependencies, orchestration becomes one of the first pressure points. Our Chief AI Officer, Varun Srinivas explored this layer of the production problem through a question that captured how quickly agent engineering has evolved: Are you still talking loops, or have you shifted to graphs yet?
With prompts becoming agents, agents starting to run loops, and increasingly complex workflows being described as graphs today, Varun's session looked past the vocabulary and examined the engineering problems underneath it.
A loop gives an agent a repeatable operating pattern. It observes the current state, takes an action, checks the result, decides whether the goal has been reached, and continues when more work remains. This structure can serve bounded tasks effectively, especially when the finish condition is clear and the required information fits within a manageable context.
Larger tasks introduce additional coordination problems. Context expands across turns, earlier errors can influence later reasoning, larger toolsets increase the chance of incorrect selection, and intermediate decisions become harder to inspect. Varun grouped the recurring issues into five areas: context bloat, error cascades, tool overload, lack of control, and limited visibility.
His explanation of graphs focused on four elements: nodes, edges, state, and policy. Nodes perform individual jobs, edges determine where execution moves next, state carries information through the workflow, and policy defines what each participant can access or change.
The value comes from the boundaries created between stages of work. Separate nodes can operate with their own context and tools, intermediate outputs can be checked before execution continues, and state can persist when a workflow is interrupted.
Varun also brought economics into the architectural decision. His session referenced Anthropic's guidance around the additional token consumption of multi-agent systems and the importance of using them where the value of the task can justify the computational cost.
The practical lesson was that agent architecture should follow the shape of the work. Teams need to consider task dependencies, context boundaries, state, permissions, checkpoints, recovery requirements, and execution cost before deciding how much orchestration a workflow needs. Varun put the architectural problem more sharply during the session, noting that “a bigger loop fixes none of these. The problem is not inside a step, it is between them.” The implication is significant because additional agent turns cannot resolve coordination problems that originate across boundaries, permissions, state, and checkpoints.
Context Engineering Starts With Choosing What the Model Sees
Once the workflow has structure, the next production problem is deciding what information each agent should receive while doing the work. Our Engineering Manager, Ajinath Ghodake covered this layer through Context Rot: Why Claude Gets Dumber in Production, examining how reliability can deteriorate as increasingly large amounts of information enter the context window.
AI coding agents often perform impressively on compact, clean projects because the relevant information fits comfortably within the working context. Large production repositories introduce years of code, documentation, dependencies, historical decisions, logs, and earlier conversation turns, all competing for the model's attention.
Ajinath referenced Chroma's Context Rot research across 18 models, including five Claude models. Among the findings highlighted during the session, irrelevant information reduced accuracy, and a 300-token input outperformed a 113,000-token context on one evaluated task.
He used the idea of a practical smart zone within the context window, with approximately 40% presented as a working heuristic during the session. The larger lesson concerned information quality and attention, since reliability can begin deteriorating well before the technical context limit has been reached.
Ajinath translated context engineering into a three-stage workflow:
Research → Plan → Implement
Research identifies the small set of files relevant to the problem. Planning converts those findings into explicit implementation steps covering files, code locations, changes, and tests. Implementation then executes against a reviewed plan where much of the reasoning has already been completed.
The workflow also creates a clearer review point for engineering teams. A plan can be examined before a large amount of generated code enters the codebase, giving teams an earlier opportunity to catch incorrect assumptions or missing dependencies.
He also recommended compacting context before it becomes overloaded, assigning isolated work to sub-agents with fresh windows, narrowing the search space before retrieval, and grounding responses in specific file and line references.
For production teams, the central question becomes highly selective: which pieces of information deserve space inside the model's context for the decision being made right now?
What Does AI Engineering Look Like When the Datacenter Fits in Your Pocket?
On-device AI makes the surrounding engineering impossible to ignore because inference has to share the same hardware as the product experience running alongside it. Saiganesh Menon, Product Consultant at Crelio Health, discussed the realities of shipping AI directly on a mobile device.
Drawing from the development of Off Grid, an application built to run AI models locally without relying on internet-based inference, he walked through the engineering involved in running text generation, vision, image generation, and speech workloads across mobile hardware.
On-device AI brings processors, memory, model formats, drivers, thermal limits, operating systems, and application rendering into the same engineering problem.
One of Saiganesh's central points concerned memory bandwidth. During text generation, model weights repeatedly move through memory, which means inference speed can become constrained by the rate at which the system can read those weights.
Quantization therefore affects runtime behavior alongside model size. Smaller representations reduce the amount of data that needs to move through memory for every generated token.
Different workloads also favor different processors. In the implementation discussed during the session, image and vision workloads benefited from NPU execution, while text generation stayed on CPU or GPU paths where memory bandwidth played a larger role.
Mobile AI also has to share hardware with the product experience surrounding it. The GPU performing inference may simultaneously be responsible for rendering the interface, and Saiganesh described an incident where unmanaged competition for GPU resources contributed to a 22.8% Application Not Responding rate. Driver behavior varied across devices as well, creating failures that became visible through testing on actual hardware.
AI agents accelerated parts of development across knowledge acquisition, debugging, testing, and repetitive engineering tasks. Device behavior still required measurement, while product decisions around feature readiness and acceptable behavior continued to rely on human judgment.
His notes captured the relationship neatly: agents made writing the code cheaper, while devices and engineering gates determined what was true. For teams exploring on-device AI, production feasibility depends on understanding the complete execution environment in which the model has to operate.
How Do You Find the AI Failures Worth Fixing First?
Once an AI system begins interacting with real users, teams need a reliable way to understand where its behavior is falling short and which problems deserve attention first. During his session ‘Beyond Automated Evals’, Aditya Kabra, Co-founder of Applicative AI, focused on the ways teams can turn scattered AI failures into something they can investigate systematically.
A support bot may misunderstand a request, lose earlier conversation context, take the wrong action, provide an unclear response, or produce an answer that appears plausible while failing to solve the user's actual problem. Aditya's approach started with manual error analysis using a small sample of real interactions.
The reviewer examines what the user asked, the context available to the system, the response generated, and the action ultimately taken. Incorrect interactions then receive a plain-language note describing what went wrong.
Patterns begin appearing once enough examples have been reviewed. Similar errors can be grouped into failure modes, which can then be counted and prioritized, giving teams a clearer view of where the system struggles most frequently and which problems deserve attention first.
The process then becomes iterative. Teams change the prompt or workflow, collect new interactions, repeat the analysis, and measure whether the targeted failure mode has moved toward an acceptable level.
Aditya also showed where automation becomes useful once humans have established meaningful categories. Domain experts review interactions, classify correctness, write failure notes, and define recurring failure modes. AI can then use those examples to find similar cases across a larger dataset and flag new occurrences.
Domain expertise remains central because quality depends on the problem being solved. A reviewer unfamiliar with a specialized field may overlook an error that an experienced practitioner would identify immediately.
Evaluation becomes much more useful once it gives teams a concrete picture of how the system fails, how frequently each failure occurs, and where the next engineering effort should be invested.
Four Sessions Focused on the Same Production Discipline
Varun's work on agent architecture, Ajinath's focus on context quality, Saiganesh's experience with hardware constraints, and Aditya's approach to evaluation all operate at different layers of the AI stack. Taken together, they point toward a common requirement: production AI needs deliberate control over uncertainty.
Human judgment remains embedded throughout those decisions because engineering teams still have to determine what context an agent receives, which tools it can access, what state persists between steps, where execution requires verification, how the system recovers from failure, and what acceptable quality means within the relevant domain.
Most of those decisions remain largely invisible during an early demo because controlled conditions remove much of the uncertainty. Production brings them into view as usage, complexity, dependencies, costs, and operational consequences begin accumulating.
Where Coditas Takes the Conversation Next
AIFwd was created as a practitioner-led community where engineers, founders, product professionals, AI leaders, and emerging talent can exchange production lessons and deliberate on the engineering practices developing around AI systems. We plan to build the initiative into a recurring platform for technical conversations, practitioner learning, workshops, and future community events.
Varun captured the production threshold in one line during his session: “You stop prompting the agent. You build the thing that prompts it.” That idea also captures Coditas’ position on production AI. The engineering challenge is to design the context, orchestration, controls, evaluation, and recovery mechanisms around model behavior so teams can operate AI systems with clear boundaries and accountability.
AIFwd will continue bringing practitioners together to unpack the engineering questions emerging around production AI. If you are building AI systems, working through similar challenges, or want to be part of the next conversation, connect with our experts and stay updated on the next AIFwd event .
