The best AI tools I've seen in the last 3 months aren't agents or workflows. They're building blocks. Small, composable tools that others can compose into their way of working. This post is about why that matters and how to ship the right abstraction.

Ship composable tools

I've seen a natural inclination towards shipping whole workflows (orchestrations of multiple tools) instead of just the tools themselves. The AI landscape is so vast and no two people seem to gravitate towards the same workflow. A workflow shipped is oftentimes heavily tied to the individual preferences of its builder.

This is stopping adoption by peers. It looks promising at first, but hardly fits in one's own workflows, so it ends up only being used by its author. Actually it's the parts of the workflow, the individual tools, that make something valuable to others. Break the workflow down into its smallest viable tools, remove the orchestration and ship a toolbox instead of a workflow.

Others can pick and match those tools into their own workflows. There is a large overlap in what tools we need but also a large divergence in personal preference for orchestration. Untying tools from specific workflows makes the tools more valuable to others, this can drive adoption and in return improve your tools when you get improvements and PRs back.

Don't get me wrong: Orchestrations are useful. But they are very opinionated. You're shipping an automated version of yourself using different tools in a different order based on different outcomes. This is immensely powerful to scale yourself. When shipping the building blocks of the workflow as individual tools and then the orchestration as a skill on top you have best of both worlds. It's easier to fork the orchestration. It's easier to contribute if others understand the individual tools in their own workflows first.

Ship skills & CLIs, not agents

Agents with their own UI look shiny, they let you control how the user experiences your workflows, but they often lack interoperability with other agents. Thing is, I already have my agent of choice: Claude Code. If I can't use it with my local agent it gets an order of magnitude harder to meaningfully integrate into my workflow.

Shipping an agent is probably the right decision if you want a clean, user-facing product and your users are not interested in composability. In all the other scenarios think about how you can ship the same unlock without forcing users into your UI. As stated above, ship the tools. Maybe your agent can be a skill that orchestrates the tools, maybe it can just be a CLI that calls an API with some AI endpoints.

If you still want to make it an agent think about how to make it accessible to other agents. Wrap the agent itself with an HTTP API, MCP or CLI. This way I don't have to leave my preferred environment, and can automate the use of your agent itself.

Ship the right abstraction

The following abstractions are listed from simplest to most complex. Each one can incorporate the ones before it. Default to the simplest that works.

Skill

The most basic way to add context through progressive discovery.

Good fit for:

• Design systems
• Tone guides
• Report structure and templates

Also useful for:

• Accompanying CLIs and APIs to give the agent the right context to get started right away
• Orchestrating the use of other skills

HTTP API

Interact with data, process things, wrap deterministic behavior, offer an interface to AI workflows and agents.

Pair with a Skill to let the agent know how to start and what calls are available.

Progressive discovery can be applied here. Only include the happy paths in the skill file and let the API return instructions on how to continue or recover if something goes wrong.

CLI

Either for wrapping more complex deterministic behavior behind an easy to consume interface (e.g. generating a PDF with company logo footer), orchestrating multiple HTTP API calls, or storing local state.

Local state management is an underappreciated strength of CLIs. Agents are bad at maintaining strict patterns in files across turns. They forget to write, write at the wrong time, or invent structure. A CLI can wrap this cleanly and deterministically write state before or after HTTP calls.

Progressive discovery applies here too. Document the happy paths in a skill file and use CLI output to tell the agent what to do next.

Agent

Uses multiple tools (Skills, APIs, CLIs) in multiple turns to produce more sophisticated outcomes. The same can usually be achieved with a skill that orchestrates multiple tools.

Trade-off: Agents are often the "end of the line". They cannot be easily orchestrated into other workflows without copying state between different windows. wdyt When it's the right choice: When it takes away the pain of complex permission and tools setup, as it can be shipped as a "whole experience".

Conclusion

Resist the urge to ship a whole workflow. Break it down and ship the smallest tool that solves a real problem. We all have our opinions on how to orchestrate tools. Keep it agnostic and let users decide how it fits into their workflows.