LLMs Generate API-Centric Agents
Filip Kozera, CEO of Wordware, on the rise of vibe doing
This reveals that the winning agent stack may look less like a chatbot picking from a menu of tools, and more like a model writing small programs against normal APIs. In practice that means the agent gets cleaner inputs, makes fewer round trips, and can handle retries, branching, and state in code instead of through a fragile tool calling loop. For a product like Sauna, that matters because speed and reliability decide whether an agent feels like a real chief of staff or a demo.
-
The product is built around long running work across email, Slack, files, calendars, and project docs, with sandboxes that stay alive and memory that compounds over time. That kind of workflow is harder to run through raw MCP because the agent is not just fetching data once, it is coordinating many steps and revisiting them later.
-
The clearest comparison is between direct API execution and one off computer use agents. Sauna is optimized for sub one second back and forth and background execution, while Manus is described as snapshot based and slower to resume. That pushes the architecture toward code driven API calls and away from wrappers that add latency.
-
This also explains why specialist tools and platform bundles are a threat. If Microsoft, OpenAI, or a focused startup can make one workflow feel faster and more dependable, users will choose that over a general agent. Wordware has to make the underlying harness, not just the model, noticeably better at getting real work done.
The next phase of agents will likely treat MCP as a compatibility layer, not the main runtime. The durable advantage will come from turning messy app integrations into fast internal APIs, then letting models generate and repair the code that uses them. That is how general purpose assistants start to behave less like chat interfaces and more like software that actually runs a workflow end to end.