From chat to execution: building agents that finish the work
A useful agent needs more than a good answer. It needs a plan, tools, a place to work, and a way to know what happened next.
Writing & ideas · 24 articles
Field notes on building AI agents that get useful work done, the products around them, and the developer tools I make along the way.
A useful agent needs more than a good answer. It needs a plan, tools, a place to work, and a way to know what happened next.
Notes from building ISTMX Skills: making practical software workflows reusable across coding agents without tying them to one stack.
A browser, terminal, files, and applications give an agent a place to act. Treating that environment as its own layer makes the system easier to extend.
Keep task state structured, retrieve relevant context when needed, and let an agent find the right memory without stuffing every document into every request.
A multi-agent system works best when specialist roles serve one clear goal and a main agent stays accountable for bringing the result together.
Noiseless explores a simple idea: monitor a topic on the schedule you choose, prepare a useful digest, and deliver it where you already work.
CodeCat uses a multi-provider fallback approach so a temporary issue with one AI provider does not have to stop a code review.
An AI feature lives inside a whole product. Web and mobile interfaces, backend services, and persistent state all shape how people use it.
A Python API around a model needs clear boundaries, validation, and predictable failure behavior before it needs more endpoints.
Types are most useful when they describe boundaries clearly and catch mismatches before a request reaches production.
Long-running agent work needs a lifecycle that survives a browser tab, a request timeout, and a temporary provider failure.
Retrieval quality depends on what gets indexed, how it is chunked, and whether search finds evidence relevant to a question.
Fluent text is not proof that an agent completed the work. Evaluation should check the artifacts and constraints that matter.
An agent can only choose tools well when names, descriptions, and input requirements make actions understandable.
Instructions found in a webpage or document should not gain the authority of the user or system processing it.
Explain what happened and what someone can do next without pretending to know more than the system does.
A mobile app should let people start, follow, and revisit work without requiring them to keep a screen open.
Shared contracts help web and mobile clients agree on data, while platform-specific UI keeps each experience natural.
Knowing who made a request does not tell you whether they may read or change a particular resource.
A task record should preserve enough state to show progress, retry safely, and return finished artifacts after a worker exits.
Shared types catch client-server mismatches, but they do not replace runtime validation or stable API design.
Streaming can make waiting feel responsive, but the interface should distinguish generated text from completed work.
A useful trace links the request, model calls, tools, and final outcome without exposing secrets.
Changing AI output makes status announcements, keyboard access, and reduced-motion behavior especially important.