Autonomy and control are not opposites, they go together: EY GDS at DevSparks Chennai

An AI agent is a system that interprets context, reasons about a goal, and decides which tools to use to reach an outcome. It does not merely execute a fixed sequence of instructions. Traditional software relies on deterministic rules and stage gates that must be cleared before production.

For example, an agent handling a credit-limit request may retrieve policy, gather data, interpret the customer’s situation, and make a recommendation. Its path can change with the context. A rules-based program would follow predefined decision steps instead.

This difference matters because flexibility is not the same as reliability. Agents need controls that restrict and verify their actions. The article describes a progression from task-based agents to goal-oriented agents and, eventually, teams in which humans and agents work together. Production success depends on the wider engineering system, not just the model.

Moving an AI agent from a demo into production means making it reliable under real operating conditions. The system must handle real customers, regulated data, compliance requirements, integrations, and business-critical workflows. The central question changes from “does it work in a demo?” to whether people can trust it repeatedly.

The article compares a hackathon build with cricket net practice. A few lines of Python and an API key may produce an impressive demonstration. In production, the agent must operate under pressure, much like scoring 12 runs from six deliveries. It also needs identity, permissions, audit history, controls, and escalation paths.

The difficult step is industrialization, not simply accessing intelligence. Cloud services, low-code tools, and open model APIs have lowered the entry barrier. The remaining challenge is building a complete system that is secure, repeatable, scalable, accountable, and ready for business consequences.

The first maturity level is the task-based agent. It automates specific steps and returns an output. This is the most limited form because the task and expected result are relatively defined.

The second level is the goal-oriented agent. It receives an objective, such as deciding how much credit limit a customer should receive, then assembles its own data and policies to produce a recommendation. The third level is humans and agents as one team. Agents handle more work, while people retain judgment for critical calls.

These levels describe increasing autonomy, not automatic readiness for production. Each step demands stronger engineering around domain context, controls, identity, security, integration, and auditability. The article presents the levels as a way for organizations to locate their current position and understand what must be strengthened before agents handle higher-stakes work.

Autonomy increases engineering work because an agent is not limited to a fixed path. It interprets context, reasons about goals, and selects tools. That freedom can help it handle varied situations, but it also creates more ways for an action to be wrong, unsafe, or outside policy.

People therefore need to constrain, restrict, and verify the agent’s behavior. In a credit-limit workflow, the agent should retrieve the applicable risk policy first, use relevant data, stay within policy guidelines, and transfer high-risk cases to a human. Its actions and decisions must also remain auditable.

Controls are not the opposite of autonomy in this model. They make autonomy usable in production. Organizations need agent identities, permissions, owners, escalation points, anomaly detection, circuit breakers, rollback, and human intervention. The more independently an agent operates, the more carefully the surrounding system must govern it.

When an autonomous agent makes a mistake in a business-critical workflow, the result can extend far beyond an incorrect answer. The article names bad transactions, financial loss, reputational damage, and security or privacy failures as concrete exposures. These consequences are why a successful demo is not enough.

Consider a credit-limit request. If the agent uses the wrong policy, misreads relevant data, or approves a risky case without escalation, its recommendation may affect a real customer and the business. A production-ready system must preserve the history of what happened so the decision remains auditable.

The response is not to remove autonomy entirely. Organizations need controls that evaluate quality, bias, and risk, plus anomaly detection, circuit breakers, rollback, and human escalation. The key standard is repeated trust under real operating conditions, not one successful demonstration.

An agent passport is the operating identity record for an AI agent. It should include the agent’s identity, a named business owner, a named technical owner, defined permissions, and escalation points. These details show who is accountable and where the agent is allowed to operate.

In the article’s bank example, the agent must establish identity, retrieve the applicable risk policy, access relevant data, and follow policy boundaries. If risk is high, it should transfer the case to a human. The agent’s history must be preserved so every step is auditable. Permissions limit its reach, while escalation points define when people take over.

These safeguards matter because organizations already have deprecated software they cannot account for. Agents could multiply that problem faster. Production systems also need anomaly detection, circuit breakers, the ability to halt execution, rollback, and human escalation.

Ontologies are structured representations of business knowledge, including a domain’s taxonomy and decision logic. They give an agent the context needed to understand the work rather than treating every problem as generic. The article notes that mature vendors now ship such domain foundations by industry.

They must work with two other foundations. Controls evaluate outcomes for quality, bias, and risk, while producing traceability. The platform makes execution repeatable and scalable. In a credit decision, domain context can guide policy interpretation, controls can check the recommendation, and the platform can run the process consistently.

None of the three is sufficient alone. Ontologies without controls can create chaos. Controls without a platform are not repeatable. A platform without domain context is generic. Together, they support production systems, alongside data, cloud and compute, APIs, security, responsible AI, and cost discipline.