Agentic AI: Faster Startups, Fragile Systems

A two-person startup that ships a new release every two weeks, closes its funding round in ten months and lets AI agents handle onboarding, legal review and customer support. That is the picture of the new startup that Vivian S. Lee, Linda Mantia and Jon McNeill paint in a Harvard Business Review article that I read in HBR Türkiye’s July–August 2026 issue. Their argument: agentic AI is the biggest change in how companies are built since the internet, and established companies are structurally badly placed to respond.

I think a large part of that argument is right. But reading it as an engineer, I kept noticing what is missing: the failures, the independent numbers and almost everything about security. This post summarises the article and then fills in those gaps.

From tools to teammates

The authors draw a clear line between chat assistants and agents. A large language model answers questions. An agent gets context, tools and permission to act, and can carry out a multi-step task on its own, such as building a five-year financial projection from a business plan. An agentic system is a network of specialised agents coordinated by a “manager” agent, pursuing a business goal rather than answering a single request.

Their examples are concrete. At NTT Data, an agentic system in customer support does not just close tickets: it spots patterns across thousands of conversations, detects software bugs, writes change requests and tests code fixes. An onboarding agent built by the startup Ema orders a new employee’s badge, assigns a desk, sets up the laptop, activates payroll and benefits and schedules introduction meetings, work that in most large companies is spread across HR, IT and three different managers.

The five forces

Based on research on dozens of AI-native startups and interviews with founders, investors and executives, the authors identify five forces that compound over time:

  1. Zero-lag iteration. Customer feedback goes into the product almost immediately. Reaching product-market fit for a SaaS startup used to take 12 to 18 months and often more than $1 million; AI-native teams build working prototypes in days. At Anterior, a platform for health insurance prior authorisation, designers change user-interface code themselves with an AI coding assistant, and the company ships a release every two weeks.
  2. Automated go-to-market. Agents generate and test marketing content and take over customer onboarding. The supply chain startup Atomic builds live demos on a prospect’s own data within hours and completes onboarding in roughly a quarter of the usual SaaS time.
  3. Autonomous business functions. A classic product team of six to eight people is replaced by two: a domain expert and an AI engineer. At the restaurant analytics startup Tactix, one engineer does the work of ten. Anterior uses agents to pre-review contracts and says this cut its legal costs by about 90%; 30 of its 40 employees work on the product.
  4. Radical capital efficiency. LangChain closed a $25 million Series A in ten months. The AI-native startups of the venture studio DVx Ventures spent about $2 million on average before Series A, which the authors describe as 80% less than their earlier companies, and reached that point 20 to 40% faster.
  5. The AI flywheel. The more the agents are used, the more data and workflow knowledge they collect, and the harder it gets for customers to switch. Anterior’s agents structure messy medical records that often run to 600 pages per case, including faxed PDFs.

For established companies, the authors’ diagnosis is sharp: the problem is not a lack of AI tools but the architecture of the organisation itself. Roles built around stable processes, middle managers who defend their territory, siloed data and technical debt all slow adoption. The most common mistake is automating a broken process instead of redesigning it, and they quote Michael Hammer’s 1990 advice: “Don’t automate, obliterate.”

What the article does not say

Most examples come from the authors’ own portfolios. Jon McNeill is CEO and co-founder of DVx Ventures, which built Atomic and Tactix, and the “80% less capital” figure comes from DVx’s own companies. Vivian Lee and Linda Mantia advise Ema, and NTT Data is one of Ema’s customers. The article mentions these links, and the authors clearly know the field well. But it means this is an investor’s view from inside the trend, not an independent study.

There are no failures in the sample. Independent data paints a more mixed picture:

  • In June 2025, Gartner predicted that more than 40% of agentic AI projects will be cancelled by the end of 2027 because of rising costs, unclear business value or inadequate risk controls. It also warned about “agent washing”: of the thousands of vendors claiming agentic products, it estimated only about 130 were genuine.
  • MIT’s report The GenAI Divide: State of AI in Business 2025, based on 150 interviews, a survey of 350 employees and an analysis of 300 public deployments, found that about 95% of corporate generative AI pilots stall without measurable business impact. The main reason was not model quality but the gap between the tools and real workflows. That actually supports the authors’ point about redesigning processes.
  • In 2024, Klarna said its AI assistant was doing the work of 700 customer service agents. In May 2025, its CEO said the company was hiring human agents again because the AI-only approach had led to lower quality, and promised that “there will always be a human if you want.”
  • In a randomised study published by METR in July 2025, 16 experienced open-source developers were 19% slower when using AI tools on their own codebases, while believing they had been about 20% faster. The sample is small, but the gap between perceived and measured productivity is worth remembering when reading “one engineer does the work of ten”.

None of this disproves the article. Startups that redesign work around agents from day one may well be the exception that succeeds where corporate pilots fail. But the speed and cost numbers in the article describe the best cases, not the average.

The engineer’s question: every agent is a new identity

Security gets almost no space in the article; it appears only as “guardrails”. For me, that is the biggest gap. Every agent that can order a laptop, change payroll or merge a code fix is a non-human identity with credentials, API keys and permissions. In my post on cloud and API security, almost every breach started with exactly these things: a role with one permission too many, a service account nobody remembered, a token that lived too long. Agentic systems multiply them.

Agents also add a risk that classic service accounts do not have: they take instructions from the content they read. The OWASP Top 10 for LLM Applications (2025) ranks prompt injection as the number one risk and lists excessive agency, giving a model too much control over tools and sensitive actions, as another. An agent that reads customer emails and can also issue refunds is an attack surface that did not exist before.

What this looks like in practice was shown in July 2025, when Replit’s AI coding agent deleted the production database of SaaStr founder Jason Lemkin, during an explicit code freeze. The agent ignored the instruction to wait for human approval, and at first said the data could not be restored, which turned out to be wrong. Replit’s CEO called it “unacceptable” and introduced automatic separation of development and production databases and a planning-only mode. Those are exactly the controls any established engineering organisation already has.

The engineering rules for agents are therefore not new, only more urgent:

  • Give every agent its own identity and the smallest set of permissions it needs.
  • Use short-lived credentials and separate development, test and production strictly.
  • Treat everything an agent reads as untrusted input.
  • Require human approval for irreversible actions: payments, deletions, deployments.
  • Log every action so you can answer “which agent did this, and why?”

The incumbents’ real advantage

To their credit, the authors see this. Agents do not always produce the same result, so they are hard to standardise and verify. Startups have to build audit trails, compliance reporting, incident response and root-cause analysis from scratch. Established companies have spent decades on those, and can use their reputation for reliability as leverage.

In the industries I know best, automotive and energy, this is not a side note. A wrong output in a car or a power system is not a bad user experience; it can be a safety incident. Functional safety standards, cybersecurity regulation and auditors do not accept “the agent decided” as an explanation. For these sectors, the winning model is probably not the two-person startup alone, but a partnership: the startup brings speed and a clean workflow design, and the incumbent brings domain experts, validation processes and accountability.

One example in the article deserves more than a sentence. As a model partnership between the military and AI companies, the authors cite the Maven Smart System used by the US Army’s XVIII Airborne Corps, which helps soldiers identify and select targets. The underlying platform comes from Palantir, and the system can feed targeting data into fire missions. Whatever one thinks of it, AI-assisted targeting is not a neutral workflow example, and it raises the questions I discussed in Authoritarian Tech and the Engineer’s Responsibility: who is accountable when an agent’s recommendation leads to harm?

What I take away

The authors’ advice for established companies is sound and worth repeating: run a risk analysis against the five forces, start with a high-friction process that is limited enough to manage, redesign it before automating it, partner with AI-native startups, define clearly when work is handed to a human, and prepare employees for new roles. NTT Data’s proposal system, which produces a first draft in 20 minutes instead of hundreds of hours, shows what a well-chosen starting point looks like.

I would add two points from the engineering side:

  • Measure, do not assume. Track cycle time, error rates and rework before and after introducing agents. The METR study shows how easily we overestimate our own speed-up.
  • Design security in from the first agent. Permissions, identities and approval steps are much harder to add once dozens of agents are running in production.

Agentic AI does lower the cost of building a company, and incumbents cannot afford to wait. But the speed advantage only lasts if the systems are trustworthy. In the long run, the winners will be the companies that combine the startups’ speed with the incumbents’ discipline, whichever side they start from.

Sources