企业软件厂商需要重新思考 AI 智能体的哪些问题

For enterprise software vendors, AI is changing several assumptions at once: how software is built, what a product looks like, where its value resides, and how customers might pay for it.

At a recent AIM Innovators session, Kevin Koenig, CTO of Aurigo, explained that these factors are quite interconnected.

Koenig organised the shift around three changes: how software is developed, what enterprise products become, and what engineers do as AI takes over more of the implementation.

“As AI makes code easier to generate, architecture, evaluation, and domain knowledge become more consequential,” he says.

While developers and engineers bet big on AI agents, enterprise software vendors will account for the reliability and accountability of those outcomes, as well as the cost of delivering them. The challenge also requires rethinking the product experience, engineering process, and commercial model around the outcomes AI can deliver.

Koenig’s arguments stem from Aurigo’s work.

The company develops enterprise software for capital program management. Its Masterworks platform serves as a system of record for projects ranging from roads and highways to data centres and utilities.

The company is building agents into an existing operational system that can work with domain-specific data, established workflows, and the controls enterprise customers require.

To begin with, Koenig distinguished between predictive machine learning and the reasoning capabilities of large language models.

He explained that Aurigo uses machine learning to predict outcomes based on historical data and past performance. LLMs provide a reasoning layer on top.

“We don’t believe LLMs are very good at predicting outcomes based on existing data and past performance. They’re actually typically very bad at it,” he said.

A model that generates plausible text isn't necessarily suited to predicting project outcomes, assessing risk, or producing a calibrated score; so Koenig said Aurigo uses different models for different problem statements.

“The model is only one part of what makes an AI system effective. Its performance also depends on the data, prompts, tools, validation, and deterministic logic built around it.

He highlighted how Aurigo is moving from SQL-based access towards a domain-specific data model that AI can use, incorporating machine learning based on past performance and anonymised data across its customer base.

“The data that you own is actually the true moat,” Koenig said.

Moreover, data is often tied to a specific business function, even if that is a boringly obvious statement in 2026.

In Masterworks, that context can span the capital project lifecycle, from planning and investment decisions through project delivery and operations.

Koenig argued that this domain context allows AI to produce useful results within the system of record.

That also changes how users interact with enterprise software. Instead of navigating only through fixed menus, dashboards, and reports, users can increasingly ask for information or trigger workflows in natural language.

Aurigo’s Lumina Agent Builder pushes that idea further. It uses orchestrators and worker agents to run processes in the background, while the user may see only a notification asking what to do next.

In one example, he explained how an agent could determine that a project is likely to overrun its schedule or budget.

Multiple agents could work through the underlying analysis using project data and domain-specific rules, while the user sees only the resulting recommendation or alert.

The complexity is pushed into the background, creating a new requirement: customers need to trust that the system reached that conclusion for the right reasons and be able to understand or intervene when necessary.

“Building trust, keeping humans in the loop and delivering auditability become some of the key components of delivering autonomous systems in a supportable way that customers will actually deploy,” he said.

Aurigo is deliberately keeping that architecture relatively simple for now. Koenig said the company uses a one-level tree in which an orchestrator manages worker agents, rather than a deeply nested, self-organising network.

More complicated agent topologies also create harder evaluation problems, and he expects those systems to become more dynamic over time.

Koenig’s product argument goes beyond adding a chatbot to an existing application. He expects enterprise software to move away from fixed dashboards, reports, menu-driven navigation and predefined workflows towards interfaces that adapt to what a user wants to know or accomplish.

Reporting and workflows would increasingly be assembled around the immediate task, with natural-language queries replacing much of the navigation through fixed screens.

On the other hand, data-entry systems would remain, but users would access information and act on it differently.

AI-assisted development is also changing Aurigo’s internal structure.

Koenig said the company has moved away from traditional handoffs between product management, engineering, and quality assurance, instead organising teams into cross-functional pods. Product managers, engineering leads, developers, and quality engineers work together, with AI generating much of the code and unit testing.

Aurigo has seen a 300% increase in throughput over 18 months, measured by story points.

Koenig said the company can move capabilities into production in hours rather than months, with appropriate testing.

This, along with code review, also involves determining whether a probabilistic system consistently produces the right result, at an acceptable speed and cost.

“Evaluation frameworks are critical to AI systems,” Koenig said. “When we build our products, the first thing we think about is how we're going to evaluate the output.”

Aurigo uses golden datasets with known inputs and expected outputs prepared by domain experts.

An AI agent runs the process, compares the actual output against the expected result, and scores the differences. The approach does not require identical responses on every run, but it does require a repeatable way to assess quality.

Koenig identified prompt and agent-description changes as a particular source of difficulty. “One word change in a prompt can have substantial changes in output,” he said. Performance is another constraint.

“Users have little patience. So an AI that takes five minutes to answer a prompt isn’t a very useful AI.”

This is why he expects system architects and cloud operations teams to become more important. Kubernetes, microservices, scalable infrastructure and reliability engineering remain necessary.

Koenig described the new engineering workflow as a sequence of three tasks—describe, review, and approve.

Engineers describe the intended outcome through prompts and specifications, review the AI-generated code for correctness, scalability and security, and then approve it for integration into the system.

“The need for coders is shrinking. But the need for people who can judge whether the output of the AI is correct is increasing,” he said.

Engineers still need to understand code and design scalable systems, but their responsibility increasingly lies in judging what AI produces rather than implementing every instruction by hand.

Therefore, for enterprise vendors, that means the differentiator is whether they own truly contextual, domain-specific data.

Or whether they have an evaluation loop that catches drift when one word in a prompt changes output, and whether they can preserve auditability and human intervention for customers like governments that can't deploy black boxes.

Architecture, cloud operations, and reliability engineering matter more, not less, because code is cheap to generate and expensive to run safely.

“The companies that win aren’t the ones that adopt AI fastest. They’re the ones that rethink the entire operating model, not just the product side of it, but how you develop software, how to remove bottlenecks through the entire environment to fully enable AI-deployed software,” Koenig said.