How AI agents make existing software more useful

An AI agent can make an existing tool useful in a situation its creator never designed a screen for.

I keep my projects and tasks in Things 3. Most of my work starts in a terminal or in a conversation with a coding agent, and moving a plan from there into Things meant copying every task by hand. Things didn’t need a new screen for that. It already had a URL scheme and Apple events, so I built Things CLI on top of them, and now an agent can turn our conversation into a Markdown plan, import it as a project, and read the project back to check the result.

Things does the job it always did. The agent gives its data another use, and the better the underlying app behaves, the more that works. A tool with dependable behavior and accessible data gives an agent something to work with. A confusing tool that silently does the wrong thing spreads its mistakes through a longer workflow.

I don’t think every app needs to become a chatbot. I do think we should look at what our software makes possible when someone uses it outside the path we imagined.

The useful work can outgrow the interface

A graphical interface has to choose which tasks get a place on screen. A project management app can show overdue tasks and a search field. It can’t offer a button for every question someone might ask about those tasks.

Say I want to know which unfinished jobs depend on a decision from me. Some tasks say so explicitly, others mention it in a note, and I want to leave out a project I paused. I can gather that by hand. An agent that can read the tasks can gather it too, then show me the records so I can check.

With Things CLI that’s things list today --json or things show "Launch newsletter redesign" --json, and the agent works from structured data instead of a screenshot. People still create the tasks, fix mistakes and look at the list in the app. The CLI just makes the same records reachable from somewhere else.

Existing structure helps an agent do useful work

Imagine two collections of customer information. One has consistent customer IDs, dated notes, and a clear link between a conversation and an account. The other has names typed differently across several documents.

An agent can work with either, but with the second it also has to guess whether two similar names are the same person. Better instructions don’t fix that. A plausible guess can be wrong, and the mistake is hard to spot when the result reads fluently.

So I would rather an app expose a reliable account identifier than rely on a prompt to reconstruct one from display names. When the information is genuinely uncertain, I want the result to say so.

A small interface can expose a larger capability

An application can offer commands and APIs alongside its graphical interface. A command-line tool can list records in a structured format, an API can let a client read a project, and a protocol such as MCP lets applications expose tools and context to an AI application.

CLI Tools Cabinet is a Mac app I built that catalogs every command-line tool installed on my Mac. The window is for me. Its companion CLI reads the same catalog, so an agent can run clitools list --json to find out what’s installed before writing a script, or clitools inspect gh to see how one tool works.

Each command names one action and takes the tool it acts on. A command called process with a handful of ambiguous options would be much harder for an agent, or for me, to use correctly.

I would start with a few read operations and add writes only when there’s a clear need. Things CLI can create, read, update and complete items, but I left out deletion on purpose. If I want to delete something, I do it in the Things app. Every app has to decide which operations it can safely offer, and “agents exist” isn’t a reason to make every internal function callable.

Reliable operations matter more when they are combined

A person using an app can notice something strange and stop. An agent may run through several operations before anyone sees the result.

Say a workflow creates a customer record, schedules a reminder, and writes a note. If creating the customer fails, the later steps shouldn’t quietly attach themselves to another customer with a similar name. Each operation needs to say what happened in a form the next step can use: did it succeed, which record did it create, did it change anything before the error?

Retries are another problem. If a request times out, the caller may not know whether it completed, and repeating it can create a duplicate unless the system recognizes the same intended operation. Stripe’s idempotent requests are a well-documented way of handling this, and the same concern applies to much smaller tools.

A tool that behaves well when interrupted is easier to combine with other tools, and easier for a human to debug.

Human review needs something concrete to review

A confirmation button at the end of an agent workflow doesn’t make it understandable. If the screen says “Update completed plan?”, I still need to know which plan and what will change.

I want the review step to show the proposed result. A bulk task update should list the affected task names and their new dates. An email needs its recipients and message visible. Before changing files, say which files.

How much review depends on the consequences. Reading a note and deleting a project are not the same thing.

A preview before a change and a history with a way to undo help here. They aren’t AI features, but an agent prepares larger changes faster than a person typing each one, so these features get used more. I would make changes easy to inspect before giving an agent more autonomy.

SEO Bot, the app I use to run SEO on this site, works that way. A report lists the pages and the problems. When the site has a local source folder, it can open Cursor or Codex there with the exact pages, files and tasks ready to send. How to run SEO checks from the terminal is that handoff. I pick the findings worth fixing, the agent makes the changes, and I review them before publishing. Every fix is logged with a note on what changed.

Good interfaces still help people think

There’s a version of the future where every app is a blank box waiting for a prompt. For a lot of tasks that would be worse.

Sometimes I need to see the information to know what I want. A calendar shows an overcrowded day before I can phrase a question about it. Asking for a summary is different from looking around and noticing something the summary wasn’t told to include.

A good interface gives me immediate feedback and a place to check delegated work. I can ask an agent to prepare a change, look at it in the app, and adjust a detail myself.

Faster implementation leaves room for neglected details

Agents can also make it cheaper to fix the small things that kept losing their place in the schedule. The export that loses formatting, the search result with no context, the keyboard shortcut that works on one screen and fails on the next.

Each one seems too small to interrupt a larger feature. If an agent cuts the time to investigate and fix them, I’d like some of the saved time to go there instead of into new features. I still have to notice the problem and decide how it should behave.

Delegation needs care here too. “Polish the app” can produce visual changes that make the interface less consistent. A concrete problem gives the agent a boundary: what happens now, what should happen, then check it in the real workflow.

Good software gives you something worth customizing

A dependable tool is also a starting point for a personal workflow. Maybe a local app already handles files well, but I want a different naming convention. Maybe an open source product needs one extra field to match a small team’s work.

An agent can help with those adjustments when the source and license allow it, and starting from a working product keeps behavior I’d otherwise have to rediscover. Things CLI ships with its source under the MIT license, so you can change it the same way. I wrote more about this in Liquid Software, where software comes with source its owner can understand and adapt.

A tangled project with unclear behavior is still hard to change safely, agent or not. Tests and understandable structure tell you what the customization has to preserve.

You also need enough understanding to recognize whether the result matches the problem you asked about. My free JavaScript course is a good foundation for following what an agent changes in a JavaScript application.

Small improvements can fit a very small audience

A feature doesn’t need a large market to be useful to one person. An employee might need a report grouped the way their team works. A researcher might need an export formatted for a particular tool. Someone managing family documents might want a local search that understands their folder structure.

An agent can connect existing capabilities around those needs, so the original app doesn’t have to add every variation to its main interface. That works when the boundaries are clear: people need to know where their data lives and which part is responsible when something fails.

I would rather have a small extension I understand than a chain of integrations I can’t explain, because the chain is harder to recover when something breaks.

Extending an app you already use

I would pick an app that already does its job well and look at the work around it. Where do I copy information elsewhere? Which repeated operation makes me leave the app? Which question needs several screens before I can answer it?

Then I’d look for the smallest interface that fits. A file export might be enough. A command-line tool fits a local workflow, the way Things CLI does. An API or MCP tool makes sense when an agent needs to work with the app directly.

For this site, I publish Markdown versions of posts. The HTML pages stay the same for readers, and other tools get the same content in a form they can read.

For a tool that writes, I’d begin with read-only access and a clear output, and add changes only once I can see what the agent plans to do and recover from an interruption. If the agent needs more supervision than the task did by hand, I would keep the original workflow and improve the tool first.

Want me to talk about your product? You can sponsor this site.