AI engineering is moving from demos toward production systems where evaluation, security, orchestration, and observability do much of the hard work.
2
MCP is becoming a common way to connect models and agents to tools, but useful implementations need deliberate context design, authentication, discovery, and client support.
3
The speakers expect software work to include many specialized agents that can reason, use tools, operate across local and cloud environments, and work alongside engineers.
Summary
This Day 1 compilation covers the main keynote sessions and the MCP track at AI Engineer World's Fair 2025. Shawn Wang argues that AI engineering still lacks a settled set of standard patterns, while Sarah Guo says the strongest applications combine domain knowledge, workflow design, model orchestration, and careful user experience. Simon Willison reviews recent model progress through his pelican-on-a-bicycle SVG test and explains why reasoning combined with tool use is especially useful. The MCP sessions trace the protocol's origins, show how Anthropic uses a gateway for remote integrations, and explain lesser-used features such as sampling, resources, elicitation, and dynamic discovery. Other talks cover MCP observability with OpenTelemetry, agent marketplaces, graph-based retrieval, cloud deployment with AWS, Windsurf's effort to support an entire software workflow, and Greg Brockman's view of engineering and research at OpenAI. Across the day, the practical message is consistent: agents need better context, clearer interfaces, and systems that can be tested and monitored.
AI engineering needs reusable patterns for taking applications into production
Shawn Wang says AI engineering has reached the point where teams need standard models that help them decide how to build applications. He compares this with established patterns such as ETL, MVC, CRUD, and MapReduce. His software development life cycle model puts increasing weight on evaluations, security, orchestration, and real production work. He also describes AI News, which scrapes sources, plans, recursively summarizes, formats, and evaluates the results. He uses this repeated workflow as a model for applications that make many AI calls, reduce many inputs into useful output, and then evaluate the result. He wants attendees to work out which patterns will become the shared foundation of AI engineering.
The strongest AI products package context around a user's workflow
Sarah Guo uses Cursor as an example of a product that is much more than a model and a text box. It uses different models for different jobs, packages context from files, applies prompting and orchestration, and gives engineers an interface that makes proposed changes easy to inspect and accept. She says builders should start with knowledge of a domain and its workflows. Products should collect context automatically, choose the right model at the right time, and present the result in a useful way. Her advice is to avoid making users explain everything in a prompt. She expects this pattern to apply outside coding, especially in industries where AI can address specific operational problems.
Reasoning becomes more useful when models can use tools and check their own results
Simon Willison reviews model releases with a small personal benchmark: asking text models to generate an SVG of a pelican riding a bicycle. He uses the test to compare models without relying only on leaderboards. His broader conclusion is that local models have improved sharply, while model prices and sizes have changed quickly. He is especially interested in reasoning models that can search, inspect the results, change the query, and try again. In his view, the important combination is reasoning plus tools. He also warns about the security risk created when a model has access to private data, receives malicious instructions, and has a way to send information elsewhere.
MCP began as a way to give models access to context and actions outside their context window
Theodora Chu explains that MCP grew from a practical problem inside Anthropic. Engineers kept copying information from Slack, Sentry, and other systems into a model's context window. The protocol was designed to let a model reach into the outside world for context and actions. Anthropic chose an open, standardized protocol so integrations would not depend on private deals between every tool provider and every client. MCP was launched during an internal hack week in November 2024 and gained momentum when coding tools such as Cursor and VS Code adopted it. Chu says the ecosystem still needs better servers, tools for hosting and testing, registries, security products, and integrations for fields beyond developer tools.
An internal MCP gateway makes remote integrations easier to secure and reuse
John Welsh describes Anthropic's use of an MCP gateway for internal and external integrations. The gateway gives engineers a single connection method while handling routing, credentials, authentication, rate limits, and observability. Internal services can connect to external MCP servers without each service implementing OAuth or managing user credentials itself. Welsh says standardizing on MCP avoids rebuilding similar integration code across teams and gives future protocol features a common path into the organization. The gateway also creates a central stream of standardized tool and resource messages, which makes auditing and monitoring easier. His design follows the 'pit of success' idea: make the safe, reusable approach simpler than building a separate integration.
The full MCP specification supports stateful interactions beyond simple tool calls
Harald Kirschner argues that many MCP implementations stop at tools because tool calls are easy to map to function calling. He describes less-used capabilities that can make servers more dynamic. Resources can expose files, screenshots, project settings, and other references to both the model and the user. Sampling lets a server request an LLM completion through the client. Roots can change as the workspace changes. Dynamic discovery can reveal tools only when they are relevant, such as showing a battle tool when a game character encounters a monster. Kirschner also demonstrates VS Code support for server debugging and urges developers to test draft features, contribute feedback, and build servers that are context-aware rather than simple API wrappers.
An MCP server needs an interface designed for models, not a direct dump of an existing API
David Cramer says Sentry's experience showed that MCP is a plug-in architecture for agents, but an existing API cannot simply be exposed endpoint by endpoint. Large JSON responses and too many tools make it harder for models to choose and use the right operation. Cramer recommends designing around the context an agent needs, including concise tool descriptions, useful errors, and responses that are easy for a model to interpret. Sentry sometimes returns structured Markdown rather than raw JSON because it gives the model a clearer representation of the information. He also warns that the provider may pay for unnecessary token usage when a tool returns too much data. His MCP server is still being adjusted regularly, and he says it is not a set-and-forget integration.
MCP observability needs shared tracing conventions across client and server boundaries
Alex Volkov and Benjamin Eckel describe MCP as a distributed system with an observability blind spot. A client may show that a tool call happened while hiding what the remote server did internally. They propose using OpenTelemetry traces and spans so clients and servers can send compatible telemetry to a shared backend. Trace context can be passed through MCP metadata, allowing spans from a server in the same administrative domain to connect to the client's trace. A third-party server may remain a single black-box span because its internal telemetry is outside the user's control. The speakers call for shared semantic conventions, higher-level SDK support, and platform integrations so developers do not need to build separate tracing systems for every MCP client and server.
Cloud-scale agents need model-driven orchestration, remote tools, and local execution options
Antje Barth presents AWS's approach to deploying agents at scale. She describes specialized expert systems coordinating across partner services and devices in Alexa Plus, then shows Amazon Q Developer using an MCP server for AWS documentation. AWS released the open-source Strand Agents Python SDK, which lets developers define a model, a prompt, and tools with a small amount of code. The SDK supports multiple model providers, multimodal inputs, retrieval for selecting relevant tools, and MCP servers. Barth also demonstrates deploying an MCP server as a Lambda function behind an API Gateway with authorization and session storage. Her broader point is that agent systems need the same operational discipline as other cloud services.
"The most exciting trend in the past 6 months is that the local models are good now."2:31:04
Who should watch
You are building a remote MCP server and need to decide how to handle authentication, context design, discovery, and client compatibility.
Your agent works across several services and you need a practical architecture for tracing tool calls, sharing credentials, or routing integrations through one gateway.
You are evaluating agent frameworks or coding tools and want to understand where MCP, graph retrieval, local models, and model-driven workflows fit.
