To scale AI agents, each one needs an owner, says COO running 16 of them in production

Rick Folgmann, COO of American insurtech Get Covered, published an opinion piece on Crunchbase News in October 2026 with a direct argument for anyone taking AI agents into production: the hard part isn't building the agent, it's deciding who answers for it. The company currently runs 16 AI agents covering more than 3 million rented residential units in the United States, according to the article (source).

Folgmann starts from a concrete example from the American real estate sector: a landlord has 21 days to return a tenant's deposit or send an itemized list of deductions, under penalty of double damages in case of bad faith. The law doesn't distinguish whether the letter was generated by a person or by software. Someone answers for it either way.

The problem that shows up after the prototype

The article cites two figures that help gauge the moment. Deloitte's State of AI 2026 survey found that 23% of companies already use agentic AI at least moderately, and 74% expect to use it within two years. Gartner, in turn, projects that more than 40% of agentic AI projects will be canceled by the end of 2027.

Together, these numbers describe a fast adoption curve paired with an equally high failure rate. For Folgmann, the difference between the two groups isn't technical, it's managerial. Teams that treat each agent like an employee in a regulated role, with written rules, defined scope, a named owner, and periodic review, have what they need to expand autonomy gradually.

For engineering and product teams in Brazil, the parallel holds even outside the real estate sector. Any team that has automated a support, billing, or triage flow with an AI agent recognizes the pattern: the prototype works in the demo, but no one has documented who decides to adjust the prompt, review the error log, or answer when the agent gets something wrong with a customer.

Start with work that already has rules

The article's practical recommendation is to first pick tasks where the rule already exists outside anyone's head: a law, a contract clause, an insurance requirement in a vendor agreement. At Get Covered, the example is chasing down vendor certificates of insurance, a task that consumes about three hours per property per week for teams in the sector, according to the article.

This kind of task gives two advantages to the team doing the automating. The first is that the agent has something objective to check its own output against. The second is that the team can audit the result without needing to debate value judgments.

Folgmann also cites McKinsey's most recent State of AI survey, which found that the small group of companies seeing meaningful financial return from AI, about 6% of respondents, were nearly three times more likely to have fundamentally redesigned their workflows.

In my experience, that redesign starts with writing the rule down. If a new hire couldn't follow your description of a decision on the person's first day, an agent won't follow it either.

Rick Folgmann, COO of Get Covered

Autonomy isn't a fixed property of the agent

A point that matters directly to anyone architecting these systems: the article rejects treating "autonomy" as a single attribute of the agent. At Get Covered, each agent is configured with different levels of freedom depending on the flow. An automatic reminder to a vendor whose certificate is expiring the following month goes out without human review; a response to a resident who requested an emotional support animal, never.

The exercise Folgmann proposes for any leadership team is to list every flow an agent will touch and ask one question about each: if this action goes wrong, how long until someone notices, and how much will it have cost by then? Fast detection and low cost justify giving the agent more room; the reverse calls for human review in the loop.

In engineering terms, this translates into designing the flow with explicit checkpoints, not into switching an entire agent on or off. It's the same feature-flag logic applied to decision-making: granularity by action, not by system.

A named owner, not "the model decided"

The most direct part of the article is about individual accountability. Folgmann recounts that, early in his career, he learned that every automated credit decision eventually had to be explained to a customer, a regulator, or both. "The model did it" was never an acceptable answer.

That still holds, except agents now act more often and across more systems than any underwriting model did.

Rick Folgmann, COO of Get Covered

That's why every agent at the company has a responsible person, the same way a team or a budget does. That person reviews the error log, decides when to expand or restrict the agent's autonomy, and answers for it before the customer or regulator.

Folgmann also points to a side effect of not doing this: when several teams launch agents independently, no one sees where these agents contradict each other. In a product team running multiple agents for different areas (support, billing, onboarding), this is exactly the blind spot that shows up when two agents give incompatible answers to the same customer without anyone noticing.

Where the real bottleneck is

The article's final argument is that models will keep improving on their own, but a company's clarity about who decides what doesn't improve by itself. For Folgmann, Gartner's cancellation forecast reflects exactly this: most agent projects that will fail will fail because no one defined the expected value or controlled the risk, and both are management problems, not model problems.

For those building these systems in Brazil, the angle barely changes the message: it's a call to version accountability the same way code is versioned. Documenting who owns each agent, what its scope is, and what the review process is isn't extra bureaucracy, it's what's missing to justify, with evidence, expanding an agent's autonomy over time, or to explain afterward why something went wrong.

The article doesn't detail how this governance model applies to smaller teams, nor how to measure in practice the "cost of being wrong" for each flow before running the agent in production. These are points each team still has to work out on its own, using the framework as a starting point, not as a ready-made recipe.