AI Engineer World's Fair 2025
Building Applications with AI Agents
Read the talk
Building AI Agents That Stay Effective as They Gain Autonomy
A useful agent needs more than tool access: clear interfaces, maintainable orchestration, deterministic safeguards, and an evaluation loop that turns failures into improvements.
From a talk by Michael Albada
Before you start: Familiarity with language models, API calls, and basic software testing will help; the Python example uses only standard-library features.
Why does a promising prototype remain hard to ship?
How do you turn an agent that handles straightforward requests into a system that reliably handles the difficult ones? Michael Albada approaches that problem from cybersecurity: at the time of the recording, he introduces himself as a principal applied scientist at Microsoft, contributing to Security Copilot and its agents. His background includes about two years at Microsoft, four years working on geospatial machine learning at Uber, and earlier startup work.
The talk distills his roughly 300-page book, Building Applications with AI Agents. At recording time, seven chapters were in early release and he expected it to go to print the following month. This is a slide-led overview, with supporting code examples available for deeper study: the focus is the promise of agents, the components needed for production, and the mistakes that prevent those components from delivering value.
Albada reports a 254% increase over three years in accepted Y Combinator companies describing themselves as agentic or building agents. That signals interest, but it does not establish reliability. Academic agent tasks involve sequences of tool calls, executions, and interactions with complex environments; a plausible first response is only one part of completing the work.
Albada contrasts results in the 50s, 60s, and 70s on agent benchmarks with hypothetical single-digit results five or ten years earlier. This is a broad progress comparison, not a controlled historical evaluation. The accompanying slide identifies AgentBench, CRMArena, and Mobile-Bench, with a single-app, single-task condition attached to Mobile-Bench. Accelerating capability is a reason to build, but not to expect perfection. Albada uses 70% prototype accuracy as an illustration of the easy initial progress before the increasingly difficult long tail; he does not specify a task or scoring protocol for that figure.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Agency and effectiveness are separate axes
An agent, in Albada’s definition, can reason, act, communicate, and adapt to solve tasks. The foundation model supplies the base capability; additional components make it more effective in particular environments. Following Andrew Ng’s framing, agency is a continuum rather than a binary property. Albada adds a second axis: effectiveness. More agency is useful only insofar as it helps solve the problem.
Robotic process automation illustrates why these axes must remain separate. A fixed automation can have little agency while delivering substantial economic value. Its weakness is brittleness: small input changes can break the workflow and force people to maintain it manually. Agents promise greater flexibility in responding to those changes, but that flexibility must preserve the automation’s effectiveness.
The four quadrants make the design constraint concrete. Robotic process automation occupies low agency and high efficacy; the intended destination for AI agents is high agency and high efficacy. Bad chatbots occupy the ineffective, low-agency corner. Powerful systems that act without being effective occupy the corner Albada labels “Future News Stories.” Increase autonomy only while preserving useful performance.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Expose actions, not your entire API inventory
Tool use starts with a simple extension of next-token prediction. An autoregressive model can generate a function call instead of natural-language prose. The application can then connect that call to functionality exposed through an API. This gives the model access to a much wider range of capabilities, while making the choice of exposed functionality a consequential safety decision.
The resulting model–tool observation loop repeats until the agent can produce its final answer:
- Parse the model’s output to identify the requested tool call.
- Invoke the tool.
- Return the tool’s response to the model as an observation.
- Let the model use that information to continue the task or produce the customer-facing output.
The observation matters because each action can supply information the model did not have when it chose that action.
Now consider an organization with 300 APIs. Registering 300 corresponding agent tools is not automatically a useful interface. Albada reports that exposing more tools in an individual prompt or completion reduced accuracy in his team’s experience, as tool meanings collided. He supplies no measured effect size or universal tool-count threshold. The practical response is to reduce the choices available at one time and group related functionality logically.
A tool should have a narrow scope, a specific name, and a clear description. It should feel like one human-facing action, rather than an arbitrary reflection of how the backend happens to divide its APIs. That makes tool design an interface-design problem: the model needs to distinguish when an action applies and what invoking it will accomplish.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Start with the simplest maintainable workflow
Once tools exist, orchestration determines who chooses the next step. Start with a chain if the task fits one: a known sequence is easier to measure, keeps costs down, and supports reliability. When the task requires alternatives, branching logic can let the model select a path through a predefined tree.
Cybersecurity provides a useful example. A workflow can assess an incident’s severity, decide which information is missing, and perform several hops of enrichment and reasoning. A fully agentic pattern gives the model more control: it repeatedly chooses which actions to invoke to complete the work.
| Pattern | Who chooses the next step? | Main tradeoff |
|---|---|---|
| Chain | A predefined sequence | Simple to measure and operate |
| Branching workflow | The model chooses among defined paths | Flexibility within a bounded structure |
| Agent loop | The model repeatedly chooses actions | More freedom; harder evaluation and optimization |
The recommendation is not to preserve a fixed workflow at any cost. Invoking the bitter lesson, Albada points to the moment when chains and trees become convoluted and difficult to maintain. That is a reason to consider more model-directed orchestration, and possibly fine-tuning, rather than continuing to accumulate hand-built branches.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Keep mandatory business rules outside the model
Model-directed orchestration does not require model-enforced business rules. Suppose an action is permitted only when A, B, and C are all true. Asking the model to remember and apply that rule makes a fixed requirement depend on generated behavior. Instead, expose tools that update the individual conditions, sanitize and validate those updates, and maintain the state outside the model.
The following Python example expresses that boundary using Albada’s three conditions. A and B begin satisfied while C is false. A valid update to C changes the action’s eligibility; it does not execute the action.
python
from dataclasses import dataclass, replace
@dataclass(frozen=True)
class Conditions:
A: bool = False
B: bool = False
C: bool = False
def update_condition(
state: Conditions, name: str, value: object
) -> Conditions:
if name not in {"A", "B", "C"}:
raise ValueError("Unknown condition")
if type(value) is not bool:
raise ValueError("Condition must be a boolean")
return replace(state, **{name: value})
def action_allowed(state: Conditions) -> bool:
return state.A and state.B and state.C
state = Conditions(A=True, B=True, C=False)
assert not action_allowed(state)
state = update_condition(state, "C", True)
assert action_allowed(state)
The application retains the current state and checks action_allowed at the action boundary. The model can help gather information and request updates, but deterministic code owns the mandatory gate. Validation must also establish whatever domain evidence each condition requires; accepting a boolean alone does not establish that a business requirement has been met.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Use multiple agents to control tool scope
Tool overload supplies a concrete reason to split a single agent into several. Group semantically similar tools, register each group with a specialist agent, and use a coordinator to route tasks to the appropriate specialist. The overall system can then support more functionality without presenting every tool to every completion.
That coordinated architecture differs from agents built independently by different teams discovering and collaborating with one another. Albada says most successful multi-agent systems he has seen were built by one team able to coordinate the parts. The Agent2Agent Protocol aims toward the broader interoperability problem. In the recording, he treats that as an early direction with technical and security questions still to resolve, rather than an already-solved consequence of adopting a protocol.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Define the agent through expected behavior
Evaluation is what makes architecture choices answerable. Albada again characterizes reaching 70–80% accuracy as relatively easy, without specifying a task or measurement protocol. The hard questions begin when deciding how many agents to use, how many tools to expose, which model to select, and what kind of memory to provide. Without a rigorous evaluation set, those choices are difficult to distinguish from guesses.
This suggests test-driven development for agents: define the inputs and expected outputs, then improve the implementation against that behavioral contract. Albada contrasts this with treating labeling as work to outsource to Mechanical Turk. Architects and engineers must take ownership of what the agent should do. Those expectations give the team a stable basis for decisions even as models and frameworks change.
Build the set from a recurring review process: run user inputs through the agent, inspect the outputs with human reviewers, and add reviewed examples to the evaluation set. The set grows as the team learns what its users actually need and where the agent fails.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Improve from batches of failures
Once the evaluation set exists, run it through the agent, analyze failures, cluster and summarize the outputs, and use those patterns to suggest improvements. This moves the unit of analysis from a memorable bad answer to a category of failures.
Several tools support different parts of that process:
- Synthetic inputs: IntellAgent can help generate test inputs when privacy or security prevents access to raw user data, or when the product has not shipped yet.
- Adversarial testing: Microsoft’s PyRIT supports attempts to jailbreak, red-team, or otherwise compromise an agent before release.
- Evaluation-set construction: Label Studio helps teams build labeled datasets.
These address distinct needs: obtaining cases, probing hostile behavior, and recording judgments about expected behavior.
Automatic prompt optimization and automatic prompt engineering extend the loop from identifying failures to proposing changes. Albada names Trace, TextGrad, and DSPy, describing a foundation model acting as a judge and feeding improvement suggestions back through an agent flow. His gradient analogy captures the direction of the approach; it should not imply that every optimizer in these libraries calculates the same kind of gradient.
The alternative is development by anecdote: inspect an example, make a plausible change, and hope it helps. Batch evaluation lets the team judge changes against aggregate behavior instead. Albada compares this to neural-network optimization, where larger batches can provide a better direction for an update. His reference to steps toward a global minimum is an analogy for more informed improvement, not a convergence guarantee for agent workflows.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Make deployed behavior visible
Deployment creates an observability problem that Albada likens to an iceberg. Generative models produce plenty of content, but the visible examples do not reveal the full range of customer use cases and failures. Once the system reaches users, understanding everything happening beneath that surface becomes difficult.
Detailed logs and traces provide the raw material for learning. Albada recommends OpenLLMetry and OpenTelemetry integrations, followed by clustering and automated summarization to identify the main failure categories. Instrumentation is useful when it helps the team understand what to improve, rather than merely accumulating more generated text to inspect.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Close the learning loop and provide a safe exit
Albada ranks insufficient evaluation as the largest limitation he sees. Tool design is another recurring source of failure: the agent may lack a needed tool, descriptions may be unclear or inaccurate, or several tools may overlap enough to confuse selection. Reducing the number of exposed tools is therefore not the same as removing necessary capability. The interface must be both sufficient and distinguishable.
Excessive complexity makes these problems harder to diagnose. Add a new mechanism only after testing shows that it improves the user experience. A second failure is lack of learning: generated content accumulates, but the team does not get from observations to root causes and useful changes. The engineering task is to tighten that loop, not simply to collect more outputs.
Safety adds a further requirement: the system must know when automated work should stop. Coming from cybersecurity, Albada treats agentic systems as a new class of potential vulnerability. PyRIT can support testing at multiple layers, but sound software engineering remains necessary throughout the stack. Build tripwires and detectors at different stages so critical cases can exit automated execution and fall back to human review. That safe exit is part of the design, not something to improvise after a failure.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The purpose is more useful work
Albada closes with Paul Krugman’s observation: “Productivity isn't everything, but in the long run it is almost everything.” The economic connection is output per worker: sustained improvements in living standards depend on increasing what people can accomplish. Albada sees agent design patterns as the beginning of an increase in that capacity. The ambition is not merely to produce more model output, but to help each person complete more useful work.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Generates policy-based test scenarios, simulates user conversations and diagnoses conversational-agent failures.
An open-source framework for identifying risks in generative-AI systems through security testing.
Guides for creating labeling projects and collecting annotations for datasets.
A framework for optimizing agent workflows using computational graphs and generative optimizers.
Google’s original announcement of a protocol for communication and coordination between agents from different vendors and frameworks.
An introduction to tracing LLM applications with OpenTelemetry-compatible instrumentation.
Further reading
The author’s companion repository with agent scenarios, evaluation examples and observability integrations.
The research paper introducing TextGrad and its text-based approach to automatic differentiation.
The original DSPy paper on declarative modules and optimization of language-model pipelines.
Read the complete timestamped transcript
- 0:00
[upbeat music] It's a pleasure to be with you today.
- 0:16
My name is Michael Albada, and I'm a principal applied scientist at Microsoft. And today I'm gonna be presenting on Building Applications with AI Agents. So just as a brief bio, I've been at Microsoft for about two years, where I've been one of the key contributors to Security Copilot and the recently announced Security Copilot agents, specifically working in
- 0:33
the cybersecurity division. Before that, I spent four years working on machine learning at Uber, lots of big geospatial problems, and I was in startups before that. And this talk is really a distillation of a three-hundred-page book that I have coming out with O'Reilly.
- 0:46
Uh, the first seven chapters are already up on early release on the platform, and it is going to print next month. And while I'll be focusing mostly on slides, I won't get too deep into code for this particular talk.
- 0:58
I just wanna say that there is full code examples backing everything I'm describing here. So if you wanna dive in a little bit deeper, take a look of what this looks like in actual code.
- 1:06
Um, this is to give you a brief-- a, uh, introduction to that. So to give a brief overview of what I'll be covering, I'll be talking a little bit about the promise and obstacles that we're seeing so far in agentic development.
- 1:18
I'll go through some of the core components that are required to build really effective AI systems that we get to production, and then I'll talk through some of the common pitfalls and lessons.
- 1:28
So there's a tremendous amount of excitement that's happening here. To just take one data point, if we look at the companies that have been accepted to Y Combinator just over the last three years, we've seen a two hundred and fifty-four percent increase in companies that are describing themselves as agentic or as if they are building agents.
- 1:42
Uh, certainly we're seeing a lot of increased investment. There's a lot of excitement here. Um, but I think we're also seeing that these are really hard problems that we're going after.
- 1:50
And so if we're looking at some of the leading agentic benchmarks from academia, we're seeing these are hard tasks that require a sequence of multiple tool calls, multiple executions, and really operating in complex environments.
- 2:03
If we were to go back five or ten years, we'd be in the single digits on some of these tasks. So the fact that we're getting up to in the fifties, sixties, and seventies on some of this is really impressive.
- 2:12
And I think just as Clay described, we wanna move to where, uh, the puck is moving, and it's actually accelerating in that direction. But if you're going and trying to build your own agentic system, do not expect per-- uh, perfection by any measure.
- 2:25
And it-- we're seeing it's quite easy to get to those initial prototype stages that might get you to seventy percent accuracy, but it's increasingly challenging to go after, uh, that long tail of increasingly complex scenarios.
- 2:37
So just to give a brief, uh, definition to start, I'm sure you've heard a few of these at the conference so far, but I'm defining it as an entity that can reason, act, communicate, and adapt to solve tasks.
- 2:47
And so we treat the foundation model as a foundation, and then we can add these additional components to increase the performance and effectiveness in different scenarios. There's been a lot of discussion about what constitutes an agentic, uh, system, and I think, uh, Andrew Ng helped clarify this, that it's not a binary distinction, but it really is a
- 3:05
continuum. It really is a spectrum. And what I would add on to that is there's a second axis that we should consider, which is the effectiveness of the system.
- 3:14
And so I wouldn't think about agency or the agentic-ness of your system as a goal or an end in and of itself. It is a tool to help you solve problems.
- 3:23
And so I just think as a classic example of something that has a very low degree of agency, but a really high degree of efficacy, it's robotic process automation.
- 3:32
This is a previous generation of automation that's been incredibly helpful and incredibly useful and is used by many companies and delivers a lot of economic value. The problem is those types of automations are fixed.
- 3:44
They're brittle. Small changes to the input can allow the entire thing to break. So it requires a lot of manual intervention to continue maintaining and updating these. And so I think part of the promise as we move to these more agentic systems is they're flexible, they're adaptable, and they unlock this additional capability of adapting to and responding
- 4:02
to those changing inputs. But we wanna make sure that any time we're adding agency to our system, when we're moving along the right, we're staying at that very high level of effectiveness.
- 4:11
We wanna make sure that any incremental addition towards agency maintains that high level of performance. What we don't wanna do is end up compromising the degree of effectiveness, and I think there's no shortage of bad chatbots that we've seen shipped by many companies that are relatively low on efficacy and relatively low on agency.
- 4:30
But we also want to avoid our going out over our skis, building agentic systems that are low in efficacy. That's what I would call the future news stories that all of us want to avoid so that as we're designing things, we're delivering things that are delivering value.
- 4:44
So I'll start with, uh, tool use. And I just wanna say, this is a really-- it's such a powerful idea, and it's really simple in principle. We're working with foundation models.
- 4:52
These are autoregressive generative models that are predicting one token at a time. Typically, those are predicting natural language, but they can also output function calls. And so if you are exposing tools and functionality to this language model in the attribute that we are calling an entity, all of a sudden, that agent can now invoke functions, and we're
- 5:12
now exposing the full range of tools that we can expose over APIs. So just think about the incredible functionality that you can expose to this, but also the risk and challenge that comes along with it.
- 5:22
And so it requires a great de-degree of, uh, discernment and responsibility to think about which of those functionalities we're going to expose and in what way so that we can deliver values to our customers.
- 5:32
And of course, this also operates in a loop. So we apply that parser to the outputted text, we invoke the tool, and we get some response back, some observation.
- 5:41
That's a way of providing more information to the agent that it can use to solve problems. We then continue this in a loop until we take our final output, and we generate that for the customer.
- 5:52
As you're thinking about designing and building tools, one really common fallacy I see is to think that there's a one-to-one mapping between your APIs and your tools. If you're working in an organization that has three hundred APIs, please do not register three hundred tools with your agent.
- 6:06
It will get really confused. And something we've seen empirically is that the more tools that you expose to your-- to an individual prompt, to an individual completion call, the less accuracy you see overall.
- 6:18
There's more semantic collision between those different tools. So if at all possible, reduce the number of tools that you're exposing at a single time and really try and group them together in logical ways.
- 6:28
You want to keep that scope really specific, really clear, specific names and descriptions, and those tools should really feel like a single human-facing action. So now that you've exposed this rich functionality and tools to your agent, you need to think about how you're going to invoke it and what the orchestration pattern is going to look like.
- 6:45
I would recommend that you keep it simple, and in particular, just a huge amount of, of great work can be done with these standard workflow patterns. And it's applying it-- So if it can fall into a single chain, please do that.
- 6:58
It will make it easier to measure, it will keep your cost down, it'll keep your reliability up, and it'll allow you to deliver value for customers more easily. And you can also apply different types of branching logic.
- 7:08
You can rely on the LLM to choose which path through the tree that you might want to go through. I work in cybersecurity, and applying these types of patterns works really nicely for deciding what the severity of an incident is, what additional information we need to enrich in performing and going through that multi-hop enrichment and reasoning.
- 7:24
It's incredibly valuable. Moving to-- through to a full agentic pattern is putting more power into the hands of the model. You're relying on it to choose which actions to invoke and do that repeatedly in order to solve some work.
- 7:38
And it's just harder to measure, and it's harder to get full performance out of that. But remember the bitter lesson. If you are getting to a point where your chains and the trees that you're building out are becoming so complex and so convoluted, and they're difficult to maintain, that's probably a sign that you want to move to
- 7:53
a more agentic pattern that will make it easier to maintain long term, and it might be something that you might want to start considering, uh, doing some additional fine-tuning on your model for that.
- 8:03
The other pattern that we found to be incredibly useful, and I think we'll see, uh, scale, um, in the future, is too many teams are relying on the large language model to apply the logic that they want to have applied.
- 8:15
So if you have some fixed business logic, if you on-only want to take an action if A, B, and C are correct, what you can do is expose tools to your agent to update each of those states, and you can apply sanitation-- sanitization and validation on each of those.
- 8:29
You keep your logic in determinau-deterministic fixed business logic that you can maintain over time, and you allow-- you maintain the state external to the model. And so that way, you can ensure that the correct actions are only taken when those conditions are met.
- 8:44
There's also been a real interest in moving from single-agent to multi-agent systems. I think the best reason that I know to break down a single-agent system to a multi-agent system is exactly that problem I was describing earlier with tool calls.
- 8:57
If you just start dumping too many tools into a single prompt, it'll get overwhelmed. But if you can break down those larger groups of tools into semantically similar groups, register it with a individual agent, and then rely on this coordinator to route to the appropriate agent to handle that task is a great way to continue to scale
- 9:15
as your number of tools grows, so you can handle a wider variety of, of scenarios. There's also been a lot of talk about the agent to agent protocol. It's a really exciting future direction.
- 9:25
Most of the successful multi-agent systems that I've seen have been built by an individual team that is able to coordinate that. I think what agent to agent protocol is really reaching towards and aiming towards is a future where different teams building different agents are able to discover and coordinate and work together.
- 9:40
I think we will see more of that, but it's really early days, and there's plenty of additional technical and security questions to work through for that.
- 9:47
This brings us to evaluation. My general recommendation, both, both for my team and I think for just about everyone, is invest more in evaluation. It's gotten so easy to build, and it is very easy to get to your seventy percent or eighty percent accuracy.
- 10:02
But there are so many hyperparameters to choose. How many agents? How many tools do you expose? Which model do you use? What type of memory do I want to use?
- 10:10
All of those pr-- questions are almost impossible to answer without a high-quality, rigorous evaluation set. So I really encourage everyone to focus more time on this than you think, and really, it's moving us towards a type of test-driven development with agents.
- 10:24
Your agent then becomes defined in terms of the inputs and the outputs that you're expecting, and there's a whole range of tools that you can use to then automatically improve relative to that.
- 10:33
So labeling, I think, is a bit of a bad word from all of our time in machine learning. That is the thing that we outsourced to Mechanical Turk. I think that is no longer something that we can do and that really the AI architects and the AI, AI engineers are-- who are building agents, you really need to
- 10:48
take more ownership and responsibility of exactly you want, you want your agent to do. And so spending time defining those inputs and outputs can really help accelerate your team in making all of those hard questions as you move forward, and the ground is changing under us in terms of models and frameworks.
- 11:03
And so you take those user inputs, you run it through your agent, and you get your outputs. There needs to be some amount of human review, and then you take those new additions, you add them to your evaluation set.
- 11:13
Once you have this evaluation set, you can now run it through your agent and go through our evaluation loop. You can analyze your failures. You probably want to do some type of clustering and summarization on those outputs, and you can suggest improvements.
- 11:25
And if this looks like a lot of work, fortunately, there are fantastic tools to help you with this, and it's not as hard as it looks. So a couple incredible open source libraries I recommend, Intel Agent, which is great at generating additional synthetic inputs.
- 11:37
Let's say you don't necessarily have access to your raw user data, uh, for, uh, security or privacy concerns, or let's say you're building something that hasn't shipped yet. Synthetic data can get you a long way.
- 11:49
Uh, Microsoft has also open-sourced PyRIT, which is great for red teaming agents, a fantastic idea to run and launch before you ship your agents that will try jailbreak, red team, and try and otherwise compromise, uh, your agent.
- 12:00
Great strategy to take. Label Studio is a great framework to help you build up these evaluation sets. And then there's this whole rich set of tools. So besides automatic prompt optimization, automatic prompt engineering, we also have Trace, TextGrad, DSPy.
- 12:15
All of these allow you to set hyperparameters and calculate gradients using a foundation model as a judge, so it can look at your failures and automatically suggest changes back through your flows to automatically improve your system.
- 12:28
So instead of you manually looking at examples and having to say, "Well, maybe this thing will work, and I'll run it through," there's a lot of development by anecdote happening right now.
- 12:36
And I just encourage all of us that as we build up these evaluation sets and run in batch and start analyzing at the aggregate level, it allows us to make more intelligent steps to take the parallel over to, uh, optimizing a neural network model.
- 12:49
Slightly larger batches will help us take more accurate steps towards the, the global minimum.
- 12:56
This brings us to observability. I think the iceberg is a fantastic metaphor here. We're working with generative models. They're very good at generating content. That's a very good thing, but it also is a real challenge for us as we're thinking about evaluating these systems at scale.
- 13:11
And as soon as you deploy these and get this out into the hands of customers, it becomes really hard to understand what's actually happening out there and really understanding the full range of failures and use cases.
- 13:21
So I encourage you to use tools like OpenLLMmetry and OpenTelemetry integrations. You really want to have detailed logs and tracing, and probably some way of doing additional clustering and automated summarization to understand those main categories of failure modes, so that you can optimize and improve your system more easily.
- 13:39
And now this brings us to just a few of the, the common pitfalls that we've, uh, we've seen, both internally and also speaking with folks outside of Microsoft. Just insufficient evals is far and away the, the biggest limitation and challenge that I see.
- 13:50
But also on the tool side, maybe you haven't built enough tools. Maybe the, the descriptions are not sufficiently accurate or clear. Uh, maybe there's too high a degree of semantic overlap between your tools, and so individual completion calls are getting confused between those tools and, and leading to worse outcomes than you suspect.
- 14:08
And then excessive complexity. There's so many bells and whistles these days. It's very easy to go chasing these other things. I just encourage us all, stay really focused on the principles, really focused on what we're trying to achieve, and only add additional complexity if we've actually tested and make sure that it's actually providing for a better experience
- 14:25
for our users and customers. And then this lack of learning. So tightening up the learning loop is really challenging. All of this content makes it hard to sift through.
- 14:34
And so really focusing on, uh, getting down to those root causes and suggesting improvements that will result in a better system.
- 14:42
And then the final thing I'll add is, coming from the cybersecurity division, this is such an exciting time for this technology. I think it's going to help us in so many ways.
- 14:49
But agentic systems are a new class of potential vulnerability, and so I just encourage all of us to really design for safety at every layer. Uh, PyRIT can definitely help on many layers of this, but just good software engineering and good principle, uh, principles are really critical for this.
- 15:03
And make sure that you're building tripwires and detectors at different stages of your agentic stack so that you can eject out and fall back, uh, to human review in all of the critical cases.
- 15:13
Uh, so this brings me to the end of my talk, and I think I'll just close with a, a quote that I love from Paul Krugman, that, "Productivity isn't everything, but in the long run it is almost everything.
- 15:23
A country's ability to improve its standard of living over time depends almost entirely on its ability to raise its output per worker." I really think we're at the beginning of an upshift in the amount of work that every single one of us can accomplish, and I think this new, uh, design pattern for agents is gonna help each
- 15:39
of us accomplish more, and I'm really excited about what we're gonna be able to do together. Thank you so much. [upbeat music]