QCon AI Boston 2026 marked a turning point in how teams think about AI agents. The focus has moved from building them to running them safely and reliably in production. Almost every talk at the conference returned to the same theme: agents are forcing teams to build real production infrastructure around them.
OpenAI's Martin Spier set the tone in the opening keynote. He discussed performance, but not in the narrow sense of making inference faster. There is a quiet stretch before inference where the product must make the conversation usable for the model-enough context to help, enough trimming to keep it fast. "The basics became more important," Spier said. We have spent the last couple of years learning to build AI agents. Now the question is how to run them, safely and reliably, once they are live.
The rise of agent infrastructure as a platform layer
Teams are moving beyond single-purpose applications and toward shared systems for context, tool access, identity, and state. Ideas like context engineering, MCP gateways, and semantic tool catalogs start to look like core infrastructure. As these building blocks become essential, they need clear owners and contracts.
Fabiane Nardon's talk zeroed in on the data layer. "Precision + Security + Cost," she said, describing the three forces that now shape the architecture for AI agents. Ricardo Ferreira put it even more bluntly: "Context engineering isn't a feature, it's architecture. Get this right and everything else gets easier." Vinoth Govindarajan added a rule that applies across the entire system: "Own the state. Order the mutation. Prove the action."
From prompt guardrails to trustworthy execution
Security can no longer depend on instructions in a prompt. As agents gain access to tools and files, teams need a harness-a system that sits around the model. A tool can run while the user sees nothing, so production systems require clear ownership of state, ordered writes, approval boundaries, and a real audit trail. The problem is no longer whether an agent gives a good answer, but whether the system can prove what action was taken, by which component, and under which constraints.
"The most effective orgs do two things: thoroughly improve AI usage across the SDLC, and resolve the bottlenecks that limit outcomes," said Lizzie Matusov, describing what separates teams that succeed with AI adoption from those that stall.
Adoption as an engineering operating model
Once usage spreads, the hard questions arrive quickly: who pays for this, who can call which tools, where do failures show up, and how do teams learn from them. Exposing a model through an API or handing engineers a chatbot is not enough. Teams need paved paths, shared policy surfaces, evaluation loops, observability, cost attribution, and feedback mechanisms that make the right behavior easier than the quick, risky one.
Evaluation has become a standout topic. Single-turn tests and static benchmarks are a weak fit for systems that use tools, maintain state, carry context, and behave differently across turns. Testing must get closer to the shape of the product: conversations, traces, simulations, production feedback. Without that, tests may report success while users hit failures the benchmark never exercised.
Siddharth Kodwani and Swaroop Chitlur described how DoorDash built its GenAI platform: "Write strategy early. Build around customers. Own company-fit surfaces." The approach ties the technology directly to the organization's operating model, not just its API surface.
Why this matters for general, IT and development, science and research
For teams building AI systems, the message is clear: the model is only part of the equation. The work that now determines success is the infrastructure around the agent-context pipelines, gateways, state management, evaluation frameworks, and cost controls. Agents may talk like coworkers, but they fail like software. Operating them well depends on the same lessons from platform engineering and distributed systems that have served production systems for years.
Your membership also unlocks:
