FigureAsia Reporting · Asia Leaders

Jyoti Bansal Is Putting Autonomous Agents Into Software Delivery. Harness Must Make Every Change Governable

AI can generate code faster than enterprises can validate and ship it. Jyoti Bansal is positioning Harness as the control layer around that bottleneck, where permissions, evidence, cost and rollback matter more than another coding assistant.

Harness is moving from AI-assisted coding into worker agents that test, secure, deploy and operate software. Bansal’s opportunity is to control the velocity generated by coding models without turning the delivery pipeline into an opaque autonomous system.

Jyoti Bansal is betting that the most valuable layer in AI-assisted software engineering will sit after code generation. Coding tools can create and modify software quickly, but enterprises still need to test, scan, approve, deploy, observe and sometimes reverse every change. Harness is putting autonomous worker agents into those delivery steps.

The company calls the mismatch an AI velocity paradox: writing accelerates while release processes become the constraint. Harness already provides continuous integration, delivery, security, feature management, cloud-cost and reliability products. Agents can use that context to perform work across the lifecycle.

The opportunity is to become the governed system around models rather than compete on the model itself. The risk is that an agent with production access can make a mistake at machine speed. Bansal must ensure that every action has bounded authority, evidence and a path back.

Software delivery is a control problem

A change passes through many systems: source control, tests, security scanners, approvals, deployment and monitoring. Humans spend time moving information among them and deciding whether risk is acceptable. An agent can gather context and execute routine steps.

Harness has the advantage of sitting in the pipeline where policies and outcomes are already visible. It can know which service changed, which tests failed, who owns it and what happened after a similar deployment. That operational context is more useful than a general code model alone.

The platform should not assume that faster movement is always better. High-risk systems may require separation of duties and scheduled review. Low-risk changes can be automated more aggressively. Customers need policy by application, environment and action.

Bansal should frame autonomy as graduated permission. An agent can begin by recommending, then execute in a test environment, then handle defined production tasks after it proves reliable. The path should be reversible if performance degrades.

Worker agents need narrow jobs

Harness has argued that agents should do one task well and avoid complex meshes that create non-deterministic behaviour. That design discipline is important. A test agent, remediation agent and deployment agent can have separate tools and permissions.

Narrow agents are easier to evaluate. A customer can measure whether a flaky-test agent identifies real instability or whether a cost agent makes safe recommendations. A general agent that edits code, changes infrastructure and deploys is harder to supervise.

Orchestration still matters. Agents need to pass evidence and state without silently expanding authority. The deployment agent should not inherit a security agent’s credentials. A central policy layer can approve the sequence while keeping boundaries.

Interfaces should reveal which agent acted, what version ran and which inputs influenced it. Human-readable names are not enough; immutable identities and logs are required for audit.

Evidence should travel with every change

Enterprises need to know why a change was allowed. Harness can assemble test results, vulnerabilities, approvals, cost impact and deployment history into an evidence record. The record should remain available after release.

An agent’s explanation must point to underlying data. Natural-language confidence can be misleading. Users should be able to inspect the failed test, policy or metric and challenge the conclusion.

Evidence also supports compliance. Regulated companies can show that required reviews occurred and that production access was authorised. Automated controls can be more consistent than manual checklists if logs are complete and tamper-resistant.

Customers should be able to export records to audit and security systems. Harness gains value by organising the evidence, not by trapping it. Open formats can increase trust and reduce concerns about platform lock-in.

Rollback is an operating capability

Agents will make mistakes. A safe delivery platform assumes failure and limits its effect. Before deployment, Harness can capture configuration, dependencies and health baselines. After release, it can compare metrics and roll back when defined thresholds are crossed.

Automatic rollback works best for changes with clear symptoms and a tested previous state. Database migrations, external contracts and data deletion can be difficult to reverse. Agents should classify those cases and require stronger approval.

A rollback should not end the investigation. The platform needs to preserve logs, mark the incident and prevent the same change from being retried without modification. Learning from failure is part of reliability.

Customers should test rollback through drills. A feature that exists in configuration but has never been exercised may fail during an incident. Harness can make these simulations part of readiness scoring.

Security belongs inside the delivery path

machine-produced code can increase the volume of vulnerabilities and security findings. Scanning after development creates queues. Harness is integrating security into the same pipeline so that risk can be prioritised and remediated before production.

An agent can identify a vulnerable dependency, propose an update, run tests and create a change. It should not silently suppress a finding to complete deployment. Security policy needs independent authority and visible exceptions.

Harness has also expanded controls for AI systems themselves, including discovery of models, agents and tool connections. The platform can evaluate what an application is building and the AI components it uses to build it.

Bansal must avoid overstating complete protection. Runtime behaviour, third-party services and novel attacks remain uncertain. The product should show coverage and blind spots rather than present a single safety score.

Cost governance is part of autonomy

Agents can consume computing and cloud resources continuously. A coding agent may generate more tests; a reliability agent may run diagnostics; a deployment agent may create environments. Without budgets, productivity gains can produce uncontrolled cost.

Harness’s cloud-cost products give it relevant data. Policies can cap spending, route workloads and require approval for large changes. Cost impact should appear alongside security and reliability evidence.

Optimisation agents need constraints. Deleting unused resources can save money but interrupt a hidden dependency. Recommendations should include confidence, owner and rollback. The system can automate low-risk savings after observation.

Bansal should disclose how Harness prices agent activity. Customers need predictable tiers and the ability to assign budgets by team. A platform cannot credibly govern cloud cost while making its own AI charges opaque.

The platform strategy can create complexity

Harness offers more than 15 products across the software lifecycle. Breadth creates context for agents, but it can overwhelm buyers and produce overlapping interfaces. Customers often want to adopt one module without replacing every existing tool.

A common data, identity and policy layer should make modules work together while preserving modular adoption. Open integrations with source-control, observability and security vendors are essential. Harness wins if it coordinates a heterogeneous environment, not only a fully Harness stack.

Sales teams should not bundle agents before customers have the data and processes to use them. Readiness assessments can identify missing ownership, tests or rollback. Deployment success is more valuable than a large contract with unused modules.

Acquisitions and internal products need a coherent architecture. Bansal should eliminate duplicate workflows and publish migration paths. Platform consolidation should reduce the number of decisions a developer must make.

Evaluation must occur in the customer’s environment

An agent that performs well on a demonstration repository may fail in a large monolith, regulated pipeline or uncommon language. Harness should let customers run historical replays and shadow mode before granting write access.

Metrics include task success, unsafe actions, human overrides, time saved and downstream incidents. They should be segmented by agent and action. Aggregate productivity can hide a rare but severe failure.

Model changes require re-evaluation. Harness may support several model providers, and customers may bring their own. The governance layer should version each combination of model, tools and policy.

Independent testing can improve credibility. Security researchers should be able to examine permission boundaries and instruction attacks through controlled programmes. Findings need a remediation and disclosure process.

Asia can expose governance differences

Harness operates across Asia-Pacific and India, where global enterprises, technology services firms and fast-growing digital companies have different delivery practices. Data residency, outsourcing and regulatory responsibilities vary.

Agents may act across customer and service-provider boundaries. Contracts must define who authorises production access and who receives logs. Local language support matters for evidence and incident response, not only the interface.

India’s large engineering workforce is both a market and a talent base. Agent adoption should focus on increasing the scope and quality of work rather than replacing review indiscriminately. Training engineers to design policy and evaluate autonomy can create higher-value roles.

Regional customers will judge whether the platform supports their cloud and tooling choices. A flexible control layer can expand where a closed stack would struggle.

The control layer must remain accountable

Harness is well positioned because it sits where software becomes an operational commitment. That position also makes it a critical dependency. Outages or compromised agents can affect many customers’ production systems.

The company needs strong isolation, service availability and transparent incidents. Customers should retain emergency paths to deploy or roll back when Harness is unavailable. The control layer should not become a single point of paralysis.

Jyoti Bansal has identified a real bottleneck: generated code creates value only when it can be delivered safely. Harness can become the system that governs that transition. It will earn authority incrementally, through narrow agents, inspectable evidence and reliable rollback. Autonomy should be the result of demonstrated control, not the starting assumption.