The Model Is Not the System: What I Took Away from AI Engineer

“Software factory” appeared repeatedly throughout the conference. The phrase can sound like shorthand for producing more code, faster, but the more useful interpretation is a system that learns from its own work.

A factory has a loop: Specify → build → review → verify → monitor → learn. The specification matters because an agent cannot reliably optimize toward an intention that was never made explicit. Review matters because plausible code is not necessarily maintainable code. Verification matters because completing a task is different from proving that the task was completed correctly. Monitoring closes the loop by bringing production signals, user requests, and failures back into the system.

This reframes the goal. The future of AI-assisted development is not twenty terminals filled with agents. It is a smaller number of better loops, each with clear state, useful feedback, and measurable improvement.

It also changes what should be measured. Token cost is only part of the equation. A useful factory considers model cost, human review time, rework, latency, production defects, and the long-term maintainability of what it creates.

Many speakers approached the same problem from different directions: AI systems are becoming very good at producing fluent, convincing work, but fluency is not evidence.

This is especially important in high-stakes domains. A citation can show where a number appeared, but it does not prove that the number was interpreted correctly, scoped correctly, or combined correctly with other data. Verification requires a chain of evidence.

One particularly strong principle from the finance-focused talks was that a model can decide what to calculate without performing the calculation itself. The model proposes the operation; deterministic software executes it; the system preserves the inputs, scope, and derivation. If the result cannot be verified, it should not continue down the decision chain.

The same principle applies beyond finance. An agent should not merely claim success. It should produce a receipt.

Enterprise agents have the same problem as new employees: they arrive without the organization’s language, history, systems, permissions, or unwritten rules.

Giving them more documents is not enough. More context can increase cost and confusion, while retrieval systems can stop at the first answer that looks satisfactory. Tools also plateau when agents do not know why or when to call them.

The stronger approaches treat context as infrastructure. They combine internal search, composable playbooks, permission-aware retrieval, organizational knowledge, durable memory, and a shared description of how the business works.

That last piece—an ontology—came up repeatedly. An ontology describes the real things in a business and how they relate: customers, contracts, invoices, accounts, people, systems, events, and operations. It gives agents a stable language for reasoning across fragmented databases and workflows.

The emerging architecture is compelling: thin agents over a thick ontology layer. Instead of packing every rule into every agent, the organization maintains a structured foundation that many agents can share.

Another recurring lesson was that the difficult part of a background agent is often the background.

Where does it run? How quickly can its environment start? Where does state live? What happens when a tool corrupts the workspace? How are secrets protected? Can the work resume after a failure? Can someone reconstruct what happened?

Several teams converged on similar answers: isolated workspaces, reproducible environments, durable execution, secure secret brokering, and version-controlled configuration. A filesystem also proved surprisingly powerful. Give an agent a workspace and familiar tools, and it can plan, create artifacts, preserve intermediate state, and use the same abstractions that already work well for developers.

Isolation matters because the threat is not limited to an external attacker. An agent can damage its own environment through a faulty command, a broken dependency, or a bad tool result. Keeping the agent’s control plane separate from its tools limits the blast radius and makes recovery possible.

One memorable framing was to treat internal agents like interns. Each one has a job, a workspace, a defined set of tools, and a versioned collection of skills and workflows.

The metaphor works because constraints are a feature. A narrowly scoped agent does not need frontier-level intelligence for every step. It needs a clear objective, the right context, appropriate permissions, and a way to tell whether it succeeded.

This last step may be one of the most important: turn repeated successful work into reusable skills. An AI-native organization should not treat every request as a one-off conversation. Repeated work should become a maintained capability.

Another useful idea was that tokens are not fungible. Asking a model to attempt the same task three times is different from using those tokens for three distinct roles.

An AI workflow can separate reasoning into jobs: an executor performs the task, an advisor recommends an approach, a grader evaluates the result against a rubric, and a dreamer explores unknowns and alternative strategies.

Advisor and grader passes may deliver more improvement per token than simply giving the executor a larger budget. The roles can also use different models. A highly capable model might advise or grade while a faster, less expensive model performs the routine execution.

This is a more precise way to think about orchestration. The question is not only how many tokens to spend, but what responsibility each token is serving.

MCP Apps offered a glimpse of how software distribution may change. Instead of forcing users to move among many separate applications, products can expose focused actions and interactive interfaces inside an AI host.

The key is to separate data and action from rendering. The model needs structured access to the information and tools, while the user may need a chart, form, preview, or other interactive component. A button in the interface can invoke a tool, and a tool result can return both model-readable data and a user-facing experience.

This does not eliminate traditional applications, but it creates another surface for them. Products will increasingly need to work for human users, browser agents, and conversational agents at the same time. Being agent-first will often require being API-first.

The conference included plenty of impressive model demonstrations, infrastructure advances, and predictions about what will run locally in the next few years. But the most durable lessons were less model-specific.

Models will improve. Context windows will grow. Inference will become faster and cheaper. Those gains will lift many products at once.

The harder advantage to copy is the system around the model: a well-designed environment, a curated understanding of the business, versioned skills, deterministic verification, clear receipts, and a feedback loop that gets better with use.

That is the shift I took away from AI Engineer. We are moving from asking whether an agent can perform a task to designing the conditions under which its work can be trusted.

The next generation of AI products will not win simply because they generate more. They will win because they can explain what happened, prove that it worked, and learn how to do it better the next time.