Global Head of AI Architecture says AI is an operating-model change, not a tool rollout

Manish Jain is VP and Global Head of AI Architecture at Firstsource, where he leads a team of 50 people. His focus right now is on building agentic systems that can handle multi-step work.

We sat down with Manish to learn how AI is changing his operating model. Here's what he said.

From potential to production-ready capability

I’m Manish Jain, an AI and technology leader focused on helping organizations turn AI potential into reliable, production-ready capability. I ground my work in the practical reality of transformation. I have led many AI and ML initiatives in the last several years, partnered closely with business teams, and worked on engineering and deployments where success depends on much more than selecting the right model. Architecture, data quality, security, integration, user adoption, and clear business value all have to come together.

I currently lead AI initiatives across a cross-functional organization of roughly 50 people, including software and platform engineers, AI and data practitioners, product leaders, security partners, and business domain experts. The work spans enterprise AI implementation and forward-deployed delivery. Teams work closely with customers and internal stakeholders to take high-value use cases from discovery through secure, scalable production deployment.

Our approach is intentionally cloud-agnostic and model-agnostic. We primarily deploy across Azure and AWS, and selectively use Google Cloud based on the client environment, data estate, and operational needs. Rather than designing around a single cloud provider or foundation model, we build modular architectures that allow us to choose and evolve the underlying components as requirements change. This includes the model layer, retrieval and data services, orchestration framework, evaluation tooling, observability, and security controls.

The real complexity is not simply selecting an LLM. It is integrating AI into business workflows across fragmented data sources, legacy applications, varying user permissions, and strict requirements around security, reliability, cost, and compliance. We typically begin with a focused use case and rigorous evaluation, then productionize what works through guardrails, human oversight where appropriate, monitoring, and continuous iteration. The goal is to create AI capabilities that remain adaptable as the technology changes and dependable enough for teams to rely on every day.

I am especially interested in the move from individual copilots to agentic systems that can handle multi-step work within defined boundaries. For technology leaders, the opportunity is significant, but realizing it requires disciplined engineering, thoughtful governance, and a strong focus on outcomes.

Why evaluation-first AI delivery improves outcomes

In the last year, I've moved AI delivery from a prototype-first mindset to an evaluation-first engineering discipline. A year ago, teams commonly built impressive proofs of concept quickly by connecting workflows to single models. But teams often addressed the factors determining AI's trustworthiness in production — quality, grounding, access control, failure handling, cost, and user accountability — too late.

We introduced a shared delivery pattern in which every AI use case begins with a clear definition of success, representative evaluation data, security and data-access review, traceability, and ongoing monitoring. We also built the underlying architecture to be cloud- and model-agnostic. This allows teams to evaluate the right combination of models, retrieval approaches, and orchestration patterns for each workflow without locking the product into one provider or model generation.

Practically, this resulted in less rework and more confidence in production deployments. Teams can identify quality or cost regressions before they affect users, make explicit decisions about where human review belongs, and improve systems based on evidence rather than anecdotal feedback.

Looking ahead, I believe this forms the foundation for responsible agentic AI. As systems move beyond answering questions and begin taking multi-step actions across enterprise workflows, we cannot add evaluation, observability, permissions, and governance afterward. They need to be part of the engineering fabric from day one.

How humans become more important with agentic engineering

We use AI throughout the product lifecycle. In discovery, it converts stakeholder input, customer feedback, and existing documentation into initial requirements, user stories, acceptance criteria, and technical questions. In engineering, it supports codebase discovery, documentation, implementation, refactoring, pull request preparation, and test generation. In operations, it summarizes logs, correlates alerts with recent releases, retrieves prior incident context, and narrows the search space during triage. Teams spend less time assembling context across tools and more time validating decisions, solving complex problems, and moving delivery forward.

We keep architecture ownership, security sign-off, data-access decisions, release approval, and priority tradeoffs human. These decisions require business context, accountability, and an understanding of consequences beyond what a ticket, prompt, or code repository contains. AI can analyze alternatives, identify dependencies, flag security concerns, and assemble evidence, but a responsible engineer or leader makes the decision.

We deliberately make that distinction as we move toward more agentic engineering. I expect AI to take on more bounded execution, such as implementing well-scoped changes, generating and running tests, validating deployment criteria, or proposing incident remediation steps. As this happens, the human role becomes more important, not less. Engineers define intent, permissions, quality thresholds, and rollback boundaries, then validate whether the system achieved the intended outcome.

How AI powers end-to-end engineering workflows effectively

Here's our end-to-end workflow that takes a well-defined product request through design, implementation, validation, and production release. It begins when a product manager and engineering lead define the customer outcome, constraints, and acceptance criteria. AI then synthesizes relevant business context, existing documentation, architectural patterns, and dependencies into a draft technical design, implementation plan, and test strategy. An engineer reviews that plan, makes the architecture decisions, and breaks the work into small, independently verifiable changes.

During implementation, engineers use AI within the codebase to understand relevant services, generate initial code and configuration changes, update documentation, and create unit and integration tests. Every change still undergoes source control, automated CI checks, peer review, security scanning, and the established release process. If a test fails, AI interprets the failure, identifies the likely dependency or regression, and proposes a correction, but the engineer verifies the fix before it proceeds.

After deployment, the workflow continues. AI summarizes application logs, correlates anomalies with recent releases, and surfaces relevant prior incidents or runbooks for the on-call engineer. We measure the full loop through lead time, test coverage, change failure rate, rollback frequency, and time to resolution.

This is not autonomous software development. It is a human-led, AI-augmented delivery system where AI compresses context gathering and execution, while engineers retain responsibility for design, quality, security, and the production outcome.

Manish Tells Us

AI has significantly reduced the time engineers spend gathering context and producing the first version of routine work. It helps teams move faster from an initial requirement to a structured technical approach, implementation, test coverage, and documentation.

How AI creates a better flow across functions

As for the results, AI has significantly reduced the time engineers spend gathering context and producing the first version of routine work. It helps teams move faster from an initial requirement to a structured technical approach, implementation, test coverage, and documentation. It has accelerated the development of new features and product capabilities, particularly when engineers need to analyze an unfamiliar codebase, trace dependencies, or work across multiple services.

AI also informs architecture decisions. It can quickly synthesize existing system documentation, identify dependencies, compare implementation options, surface likely tradeoffs, and help teams create architecture decision records. Humans make the final architecture decisions, but teams enter those discussions with better context. They can spend more time debating the decisions that genuinely matter, such as scalability, resilience, security, cost, and long-term maintainability.

The improvement is not simply faster code generation. We see better flow across the lifecycle because product, engineering, QA, and operations start with more complete and consistent context. Engineers spend more time on system design, edge cases, integration complexity, and customer impact instead of manually assembling information from repositories, tickets, dashboards, logs, and past incidents.

How success should be measured with AI

We have also learned important lessons about the downsides. AI can create a false sense of speed when teams accept plausible output without sufficient validation. It can generate code that appears correct but does not fit the surrounding architecture, misses subtle business rules, introduces unnecessary complexity, or creates security and maintainability issues. Productivity gains are also uneven. Engineers who understand the system, frame work precisely, and validate outputs rigorously benefit most.

That is why we measure success through delivery quality rather than AI activity metrics. The outcomes we care about are faster feature delivery, shorter cycle time, stable releases, stronger test coverage, lower rework, faster incident resolution, and sustained reliability. The longer-term opportunity is significant, but only if AI improves engineering judgment and execution rather than becoming a substitute for either.

How new constraints change team structures

Code generation is no longer the constraint to engineering velocity. The real constraints are often unclear requirements, fragmented business context, architectural dependencies, security review, integration across systems, and the time to validate that a change works safely in production. Industry data points in the same direction: coding represents a relatively small share of an engineer’s day, and AI adoption in coding does not automatically translate into proportional throughput gains.

That changed how I think about team structure. Rather than simply treating AI as a way to reduce delivery effort, we are moving toward smaller, more cross-functional teams with stronger ownership from discovery through production learning. Engineers need to spend less time creating first drafts and more time defining intent, shaping architecture, validating outputs, and improving the system after release.

Further, our hiring focus has shifted from pure coding output to systems thinking, product judgment, and validating AI-assisted work. We value engineers who can handle ambiguity, make sound architecture and security tradeoffs, and own outcomes through production.

Manish Tells Us

The future is not just faster implementation. It is faster alignment and a tighter loop between an idea, a production outcome, and the learning that informs the next decision.

The future is not just faster implementation. It is faster alignment and a tighter loop between an idea, a production outcome, and the learning that informs the next decision.

Why testing needs redesign for an AI-augmented future

Testing needs to be redesigned.

AI is making it much faster to create code, which means quality assurance must become continuous, automated, and built into the delivery flow rather than treated as a final gate. Teams need AI-assisted test generation, realistic evaluation datasets, security and performance checks, production monitoring, and clear human ownership for exceptions.

In an AI-augmented lifecycle, the competitive advantage will not be who generates code fastest, but who can validate changes safely and learn from production most quickly.

How to avoid AI friction early on

We underestimated the operational realities of AI. Token consumption and usage limits can significantly constrain delivery, especially for agentic coding workflows that need large codebase context or repeated iterations. We now treat AI spend as an engineering capacity decision, with visibility into usage, model routing, context management, and the value produced — not just a license cost. Service reliability also matters. An external model or coding platform can experience latency, rate-limiting, or availability issues, so critical workflows need fallback models, graceful degradation, and ways for engineers to continue working without the AI service.

We could have avoided early friction by defining approved tools, clear data boundaries, review expectations, cost controls, and fallback patterns from the start.

I also would not mandate a single tool or workflow prematurely. The technology is changing too quickly. The better approach is to provide secure access, reusable guardrails, opportunities for peer learning, and clear accountability. An engineer still owns what they design, review, merge, and operate in production.

Why AI should be treated as an operating-model change

My advice to CTOs is to treat AI as an operating-model change, not a tool rollout. Start with a small number of high-value workflows where you can establish a baseline, measure impact, and learn quickly. Build a shared AI platform and delivery discipline around approved models, secure data access, evaluation, observability, and reusable integration patterns, and keep the architecture cloud-agnostic and model-agnostic. That prevents every team from reinventing the same controls or becoming locked into a provider too early.

Just as important, invest in people. The organizations that will gain the most are not those that simply generate more code. They will be the ones that help engineers, product teams, security partners, and business leaders learn to frame work clearly, validate AI outputs, and operate agentic systems within defined boundaries. Move with urgency, but make trust, quality, security, and measurable outcomes nonnegotiable.

AI is becoming a core execution layer for the enterprise, so the CTO’s role is to create the architecture, governance, and culture that allow it to scale responsibly.

Follow along

You can follow Manish Jain's work on his Substack and LinkedIn.

More expert interviews to come on The CTO Club!