← All AI Engineer talks

AI Engineer World's Fair 2025

Just do it. (let your tools think for themselves) - Robert Chandler

Robert Chandler· Co-founder, Wordware6:50

Read the talk

Give your tools time to think

A failed Slack message exposes the cost of tiny API tools. Robert Chandler shows how a specialized workflow can give a general agent a simpler, more useful interface.

From a talk by Robert Chandler

Before you start: Familiarity with LLM tool calling and MCP, the Model Context Protocol, will help you follow the workflow design.

Why is sending Philip a message so hard?

Sending a Slack message to Philip should be a straightforward task for an agent. Robert Chandler introduces the problem from his experience as Wordware’s co-founder and CTO: he says he has helped hundreds of teams build reliable agents, after previously working on self-driving cars. The promise is familiar—an automated system understands you and your team, interacts with your tools, and puts useful output where you need it.

His early experience connecting Slack through MCP fell well short of that promise. He wanted to tell Philip that he was using MCP and thought it was cool. The agent listed users, became confused, listed channels, and attempted to send a message. Even after reportedly finding Philip, it resorted to posting in the general channel, asking someone else to pass the message along. Chandler reports that this unsuccessful attempt to message Philip took about five minutes. The failure points to the central design problem: many MCP servers expose low-level API operations that were never designed for a language model to coordinate.

0:000:12
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

0:00 · section reference included

Small tools make the caller do the integration

A large JSON response can be convenient for a deterministic program: code selects the fields it needs and moves on. For an agent, that same response becomes more material in the context window. When tools each expose only a small function, the model must also work out how to compose them, interpret every intermediate result, and decide what to call next. The integration logic becomes part of the agent’s reasoning burden.

Pagination makes the problem concrete. One response may not contain the user or record being sought, so the agent must request another page and continue until it finds the desired data. Each iteration extends the chain of requests and adds more output to the context. Authentication adds a separate kind of overhead: hosted MCP servers had made setup somewhat easier, but Chandler still encountered API keys and Slack bot creation. His expectation that this friction would diminish over the following months was a forecast at the time of the recording.

Tool definitions themselves also consume attention. Chandler’s historical examples are eight tools from a Slack MCP and approximately 20 more from a Notion MCP. Every additional tool brings instructions and another choice for the agent; even those two integrations do not cover the full range of useful automation. The issue is both the number of available operations and the length of the sequences needed to accomplish a task.

1:291:41
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

1:29 · section reference included

Make the tool a specialist

Chandler illustrates the mismatch with a T-Rex holding a tiny spanner, then Inspector Gadget carrying a thousand tools. A powerful caller can still struggle when its tools are too small or too numerous. His alternative is a team of Avengers: Hulk handles smashing, Hawkeye handles precision, and Iron Man might serve as the broadly capable main agent. The useful part of the analogy is specialization—each delegate owns a meaningful task.

An agent can be a tool for another agent. The outer agent needs a tidy natural-language interface and a useful result; the specialist can own the reasoning and sequence of operations behind that interface.

Design choiceFunction-sized toolSpecialist tool
ScopeOne operationA meaningful task
CoordinationCaller assembles the sequenceDelegate manages the work
ResultIntermediate API outputTask-level output

The intended payoff is a reusable interface that produces reliable, high-quality results without requiring the caller to reconstruct the workflow each time.

2:573:13
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

2:57 · section reference included

Package competitor analysis as one task

Wordware MCP Toolbox supplies the implementation in the demonstration: it turns Wordware workflows into tools that other agents can call. Chandler selects a competitor-analysis workflow from the landing page because the task combines judgment, reasoning, and integration with both Twitter and Notion.

The workflow uses Wordware’s built-in Twitter scraping tool, avoiding a separate search for a Twitter MCP server. Its analysis instructions specify what Chandler cares about instead of leaving the entire definition of a good report to the model. He could add more company context to sharpen the comparison and identify where the businesses differ. This is where the specialist acquires its task-specific judgment: the workflow encodes the criteria before the general agent invokes it.

The workflow then generates the analysis, writes it to Notion, and returns the created page’s URL. Its contract includes both producing the content and delivering it to its destination. In the editor, the completed sequence shows analysis guidelines followed by Generate Analysis Report and Create Page, with an instruction to output the Notion page URL. The calling agent can receive that link without managing each publishing step itself.

Wordware editor showing analysis guidelines followed by Generate Analysis Report and Create Page blocks, with an instruction to output the created Notion page URL.
The competitor-analysis workflow generates a report, creates a page, and returns its URL.
3:574:09
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

3:57 · section reference included

Connect the toolbox and request the analysis

The demonstrated Toolbox service is in beta; Chandler describes a broader rollout as coming soon. He uses an existing toolbox containing the competitor-analysis app he had already published, then connects it to Claude. A toolbox can group several tools, whether related or disparate, and different toolboxes can be switched on or off for different tasks. That gives the user a way to control which capabilities are available to the caller.

The invocation is a short natural-language request:

Create a competitor analysis for Anthropic AI.

Claude selects the Wordware tool and presents permission choices to allow it once or always. Chandler judges the task low risk and authorizes it to proceed. The workflow is now responsible for carrying out the analysis, rather than asking Claude to assemble Twitter retrieval, analysis, and Notion publishing from individual operations.

4:565:09
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

4:56 · section reference included

Return a result the user can find again

Chandler then introduces a prepared result: “Here’s one I made earlier.” He follows its Notion link to a formatted competitor summary, which he describes as based on all of Anthropic’s tweets. The page illustrates the intended output; it does not establish that the newly requested run has completed or independently confirm the retrieval coverage.

The report offers observations about Anthropic’s tweeting style and what someone could learn from it. Just as useful is its location: the analysis is already formatted and stored in Notion, where Chandler wants to retrieve it later, instead of being lost in a chat. The destination is part of the task’s definition of success.

Chandler characterizes the resulting tool as highly reliable, repeatable, and aligned with the task, though he supplies no quantitative evaluation. The architectural benefit is clear: a generic agent gains a specific capability by delegating to a workflow whose instructions and integrations have already been assembled for that job.

This returns to the team analogy. A generalist delegates work to a specialist with the context and capabilities to carry it through. Wordware Toolbox is one way to build that boundary, but Chandler explicitly leaves the implementation open: any platform can support agentic MCP tools. The design invitation is to give the tool enough responsibility—and enough room to reason—to complete a useful piece of work.

5:496:04
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

5:49 · section reference included

Resources

From the talk

Updates since the talk

Read the complete timestamped transcript
  1. 0:00

    Hi, I'm Robert. I'm the co-founder and CTO at Wordware, and at Wordware, I've personally helped hundreds of teams build reliable AI agents. I'm here to share a few of the insights that we got, especially when it comes to tools.

  2. 0:12

    Um, really agentic MCPs, giving your tools time to think. Before I worked on, uh, LLMs and agents, I used to work on self-driving cars and really, you know, building highly reliable systems is in my blood.

  3. 0:26

    So, uh, yeah, here we go. The promise of agents are automated systems that can take action in the real world on your behalf. They have all the context they need about you and your team, and they have the ability to actually interact with the tools you use and output kind of data where you need it.

  4. 0:42

    Unfortunately, most of the time, they don't really work. They're often slow, expensive, and unreliable. Um, I remember an example when MCP first came out, and we hooked up Slack, and it spent a bunch of time...

  5. 0:56

    You know, I just wanted to send a Slack message to Philip being like, "Hey, I'm using MCP. It's super cool." Um, unfortunately, it then, like, listed all the users in the Slack channel, got confused, tried listing all the channels, tried sending a message, actually finally found Philip.

  6. 1:09

    Uh, it ended up resorting to sending a message in the general channel being like, "Hey, could someone tell Philip MCP is awesome?" Um, which I thought was kind of amusing, but also really not what I wanted as a user.

  7. 1:20

    It also took about five minutes to do that. Um, and the real problem is that these MCPs are often low-level wrappers around these APIs that were not designed for language models.

  8. 1:29

    You know, you get these messy responses that have huge blobs of JSON, which are great for, like, deterministic state machines, but kind of suck in a kind of context pollution for agents.

  9. 1:41

    You get tools that are these tiny scope. You know, most of the MCP tools are just a wrapper around a function, and functions were designed for the programmatic world where you want to compose a lot of these, uh, tasks together into, like, s-sequences of function calls.

  10. 1:55

    That's really hard for an LLM to continue reasoning over multiple calls and, like, polluting their context with all different outputs. It's also a problem when you've got multi-call pagination, you know, when the API responds, and you need to kind of loop over the results until you get the data you're looking for.

  11. 2:10

    This really pollutes the context window, but it also means that the LLM has to reason over more and more, uh, longer chains of, of requests. Authentication's a pain. You know, it's got a little bit easier with these hosted MCPs, but still, a lot of the time, you need to have your own API keys.

  12. 2:26

    You need to be, like, m-modifying... like, creating bots and things. Um, I'm sure that will go away over the next few months, but right now, it's a bit of a pain.

  13. 2:33

    And, uh, yeah, just in general, the agents struggle when there's many tools or kind of sequences of tools to perform. Um, it's really hard. You know, every tool you adds more noise to the context window, a lot of instructions.

  14. 2:45

    Even just adding a Slack MCP adds eight different tools. If you add Notion, you add another, like, 20 different tools. Um, and those two together are sort of... you can do a lot, but it's not, like, the be-all, end-all of automation.

  15. 2:57

    So how do we solve this? Well, in my opinion, we add more agency to the tools. Rather than making these tools very small, um, think a bit like, you know, a T-Rex holding a little tiny spanner, um, uh, or like Inspector Gadget with, like, 1,000 different tools.

  16. 3:13

    Think of it a bit more like a team of Avengers where, you know, you've got specialized people for different tasks. You know, you've got the Hulk to smash. You've got, uh, the Hawkeye to fire the arrow off and, uh, really do high-precision tasks.

  17. 3:29

    Um, and you know, obviously, we all love Iron Man. He's the best, and he's just pretty good at a lot of things. Um, maybe that's the main agent. Who knows?

  18. 3:36

    I'm not sure where this analogy is going, but I'm sure it's an entertaining one. Uh, [chuckles] but really, what we wanna do is blur the line between what's a tool and what's an agent.

  19. 3:44

    Um, when is an agent just a tool for another agent? And, you know, give tidy, simple natural language APIs to these agents such that they get reliable, reusable, high-quality outputs.

  20. 3:57

    What I'm gonna do is I'm gonna demonstrate Wordware's new MCP Toolbox, and this allows you to build, uh, agentic MCPs. You can turn your Wordware workflows into tools for your agents.

  21. 4:09

    Um, and so I'm just gonna grab one from the landing page as an example. Um, and I'm picking this kind of, uh, competitor analysis because, um, that's a, a flow that requires quite a lot of taste, quite a lot of reasoning, and also integration into both Twitter and Notion.

  22. 4:25

    Um, rather than, you know, finding a Twitter MCP, um, I just use the kind of Twitter scrape tool built into Wordware, and then I've described what I really want from my competitor analysis.

  23. 4:35

    It's not just a generic whatever the LLM thinks. Um, it's kind of gone into detail about what I care about, and I could add even more details about my company and try and work out, you know, where do we, where do we differ.

  24. 4:46

    It then creates this analysis, writes the output to Notion, and then returns the URL in the output. And so, uh, I can easily do this. I can go to this mcp.beta.wordware.ai.

  25. 4:56

    So, um, still in the early days, but, um, yeah, we are rolling this out beyond beta fairly soon. And, uh, here's a toolbox I created earlier. I just added the competitor analysis after publishing this app earlier.

  26. 5:09

    I connect that to Claude, and now I can, uh, use this tool inside my Claude. And what's nice about Wordware is you can add multiple tools into this toolbox.

  27. 5:19

    So you can have a bunch of different tools that are grouped together that are all related or entirely disparate. But you can switch on and off different toolboxes for different tasks.

  28. 5:27

    But maybe let's do something like create a competitor analysis for Anthropic AI. I hit this, and now you can see it's going to use the Wordware tool. I can allow it once or can allow it always.

  29. 5:39

    You know, there's nothing too bad that can go wrong here, so I'm just gonna let it go. And now it's gonna perform this competitor analysis.

  30. 5:49

    Here's one I made earlier. Cool. So now that's done. I can grab the link to the Notion page on the competitor analysis, open that up, and we'll see a nicely formatted summary based on all the tweets from Anthropic.

  31. 6:04

    And we can see they care a lot about how they're tweeting, and so we can learn from their style. Um, and it's all in my Notion page, nicely formatted, um, and exactly where I'd want to find it again, so it's not just lost in the chats.

  32. 6:16

    So pretty exciting. We managed to build a highly reliable, highly repeatable, and highly aligned tool that allows our generic agent to be very specific and very, uh, powerful for doing that task that we wanted it to do.

  33. 6:28

    And so we've really blurred the line between what's an agent and what's a tool and allowed our agent to offload tasks to something that's more powerful. Exactly how, you know, we do this already in teams, and you have specialists for people, you know, whether it's the Avengers or your team in a company.

  34. 6:42

    You can use Wordware Toolbox to build these flows. You can use anything to build agentic MCPs. We hope you follow this pattern and give your tools time to think.