An agent needs to take actions through tools, because chat alone cannot automate business workflows.
2
Most agents fail before production because teams cannot solve authorization, cost, latency, or accuracy problems.
3
Production agents need evals, a suitable model, orchestration with human review, intention-based tools, and delegated authorization.
Summary
Alex Salazar argues that an AI system is not really an agent if it cannot take action. Chat can retrieve information, but useful software automates workflows across systems such as Gmail, Salesforce, Slack, and data platforms. He explains why demos often fail in production: authorization is difficult, long agent flows compound errors, repeated model calls raise cost and latency, and users lose trust when results are inaccurate. His proposed design starts with simple evals, then adds a model, an orchestration layer, tools, and delegated authorization. Salazar spends much of the talk on tool design. A tool should express the agent's intention, such as finding a brochure or replying to an email, rather than expose a raw API with awkward parameters. He also argues that data quality is less of a first-stage blocker than it was for older AI systems, since OpenAI and Anthropic models already handle many use cases without custom training.
An agent has to change another system to create workflow value
Salazar defines an agent by its ability to take an action. A chatbot that only answers questions is not enough, even if it has a more fashionable name. He connects action to the main value of software: workflow automation. Automation requires access to systems beyond information retrieval, such as Gmail, Salesforce, or other business applications. Arcade focuses on this layer, with agent authorization, prebuilt tools, and an SDK for custom tools and MCP servers. The practical test is simple: the system must be able to do something on behalf of a user, not only explain what the user could do.
A convincing demo can hide most of the production work
Salazar says teams often get a demo working and then discover that roughly 90% of the work remains before production. He identifies four recurring blockers. Authorization prevents an agent from safely connecting to systems such as Gmail and Salesforce. Cost rises when teams add context, chain-of-thought steps, and loops to improve accuracy. Latency becomes a problem when users wait minutes for a result. Accuracy determines whether users trust the system at all, and Salazar says agents generally need to be above 80% and probably higher for people to keep using them.
Simple evals should come before elaborate agent architecture
The first layer in Salazar's agent hierarchy of needs is evaluation. He recommends starting with a Google Sheet that lists expected inputs, scenarios, and outputs. This gives a team a basic way to check whether the agent remains within its intended use case. Agents are non-deterministic, so ordinary software tests do not cover the problem well. Defining the expected behavior first also helps teams reduce scope. The evaluation does not need to begin as a large dataset or a production-grade system. It needs to make the agent's intended behavior explicit and provide a repeatable check as the implementation changes.
Model choice matters less than tool selection and parameter prediction
Salazar says the major flagship models are now close enough that model selection is usually driven by the application, cost, and latency. He gives more weight to how well a model selects tools and predicts their parameters, since tool calling is how an agent takes action. He says flagship models are ahead of community models on this task at the time of the talk, while acknowledging that the gap may change quickly. After choosing a model, teams need an orchestration layer. Salazar does not prescribe one framework, but advises choosing a system developers can understand and one with strong human-in-the-loop support.
Tools should encode intentions instead of exposing raw APIs
Raw APIs are poor interfaces for language models. An API may require a Unix timestamp, a unique identifier for a person, or a sequence of calls that the model cannot reliably infer. Salazar uses replying to an email as an example. The agent may need to find the right message, unpack MIME, preserve the thread, rebuild the message, and send it. A tool can hide that fixed sequence behind an intention such as
Delegated authorization combines the user's rights with the agent's registered scope
Salazar describes two unsafe patterns. Giving an agent its own broad identity creates questions about whose data it can access. Giving an MCP server the user's full credentials is safer in one sense, but lets the agent perform actions the user may not want it to perform automatically. His preferred approach is delegated authorization. The allowed action is the intersection of what the agent is registered to do as an application and what the user is permitted to do. If either side lacks permission, the action should be denied. He says this approach is difficult, and describes an MCP specification contribution intended to make it easier across vendors.
Clean data is valuable, but it no longer has to block the first agent release
In the question period, Salazar contrasts older AI development with what he calls new AI. Older systems placed model training, data quality, and labeling at the center. He says current agent development looks more like software composition: developers assemble models, orchestration, tools, and authorization. His view is that OpenAI and Anthropic have already done enough work for many common use cases, so teams can begin with an unoptimized model implementation and consider fine-tuning later if needed. He does not dismiss clean data. He says clean, plentiful data remains highly valuable, but it is no longer a gate for starting many agent projects.
