API wrappers make LLM tool use slow, expensive, error-prone, and unsafe because models must reason through interfaces designed for software engineers.
2
Machine Experience engineering creates simpler tools for models, while the tool handles API pagination, lookup, matching, and validation in ordinary code.
3
Tools should be deterministic and return useful error context, while the agent decides whether to ask the user, involve a human, or try another action.
Summary
The talk introduces Machine Experience, or MX, engineering as the design of interfaces for AI models. The speaker uses a Slack DM example to show how an LLM must search users, inspect conversations, retrieve members, paginate through results, and translate names into IDs when exposed to the raw Slack API. That process consumes tokens, takes time, creates opportunities for hallucination, and gives the model too much freedom around sensitive actions. A better tool exposes one simple send-message operation and handles the complex Slack API work in tested Python code. The speaker argues that tools should behave deterministically. When a username cannot be found, the tool should report the failure and provide relevant data, such as available users, without guessing. The agent can then ask the user to clarify. Good MX should also borrow familiar behavior from graphical interfaces, such as fuzzy search, so agentic interfaces do not feel worse than the software people already use.
Raw API endpoints force models to solve the wrong problem
The Slack example shows an LLM trying to send a DM by working through low-level API endpoints. It must identify the right conversation, inspect members, find Eric's user ID, and deal with pagination and missing names. The chat request uses a person's name, while the API expects IDs. That mismatch forces the model into a long chain of reasoning for a simple action. The speaker says API wrappers commonly expose a large JSON description of these endpoints and ask the LLM to figure out the sequence itself.
Direct API exposure makes tool use slow, costly, and unsafe
When an LLM has to reason through many endpoints, each step consumes time and tokens. The speaker says this makes the process expensive and prone to mistakes, including hallucinating an email address or selecting the wrong user. There are also few guard rails because the model can operate directly on the API. Confusing names such as chat.postMessage, conversations.list, channels, and conversations make the interface difficult even for software engineers. The resulting machine experience affects the user experience because unreliable agents lose people's trust.
A good tool hides API complexity behind one focused operation
The proposed send_message tool accepts a message and one or more usernames. It can also accept a channel name, conversation ID, user ID, or email when those values are already available. The tool performs the searching, matching, pagination, and iteration internally before calling Slack. The LLM therefore makes one short call instead of reconstructing the entire workflow. Python annotations tell the model which identifiers are useful, while ordinary code handles the complicated integration work.
Tool interfaces should give models several valid inputs without making them reason about alternatives
The tool can receive Eric's username, John's email, a conversation ID, or a combination of identifiers. The implementation decides how to use those values. If a conversation ID is already in the model's context, the tool can skip the lookup process. This gives the model flexibility at the boundary while keeping the internal behavior predictable. The speaker says a small model can call the simple interface accurately because it does not need to plan the underlying Slack operations.
If a user mistypes a username, the tool should not simply end the interaction or guess silently. Since it has already searched Slack, it can return the failed name along with users that may be relevant. The LLM can then ask whether one of those users was intended. If the user confirms, the model already has the ID needed for another tool call. This produces a better conversation while keeping the tool from inventing a correction.
Tools should be deterministic while agents decide how to react
In the question period, the speaker draws a firm boundary between tools and agents. A tool called with the same parameters should behave the same way every time. It should fail when the exact requested username does not exist rather than choosing a similar account. The agent is nondeterministic because it needs room to respond to user requests. Agent developers decide whether a failure should lead to another attempt, a clarification question, or human input.
Agentic interfaces should match familiar graphical interface behavior
Users bring expectations from graphical interfaces into chat and voice agents. In Slack, fuzzy search can find a person even when the user makes a small typo. If a chat agent responds that the name does not exist, it feels worse than the interface people already know. The speaker argues that agentic interfaces should provide at least the same useful behavior, such as offering likely matches, while adding the benefits of natural-language interaction.
MX needs its own evaluation criteria because existing APIs were built for humans
The speaker says APIs from Slack, Google, GitHub, Microsoft, and Atlassian were designed for software engineers. Their flexibility and guard rails reflect how human developers work, while LLMs make different kinds of mistakes. He has not seen an API that provides good machine experience without substantial translation. For UX, a useful reference point is the corresponding graphical interface. Teams need to compare what users expect there with how the agent handles the same action.
