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.

A person might ask for a list of unresolved support requests, compare them with recent releases, and turn the result into a draft report. Several products already hold the information. The missing piece is the work of connecting them for this particular question.

That possibility makes me more interested in good software.

A tool with dependable behavior and accessible data gives an agent something useful to work with. A confusing tool that silently does the wrong thing can spread its mistakes through a longer workflow.

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

The useful work can outgrow the interface

A graphical interface needs to choose which tasks deserve a place on screen.

A project management app can show overdue tasks and provide a search field. It cannot offer a dedicated button for every question someone might ask about those tasks.

Suppose I want to know which unfinished jobs depend on a decision from me. Some records say that explicitly. Others mention it in a comment. I also want to exclude work that belongs to a project I paused.

A person can gather this information manually. An agent with appropriate access can help gather it too, then show the relevant records so I can check the result.

The app still stores the tasks and their relationships, giving the agent useful information to work with. People still need to create work, correct mistakes, and understand what their colleagues are doing.

The agent gives the information another use. That distinction matters because it suggests a practical direction for software design. Make the underlying capabilities understandable and accessible, while preserving a good experience for people doing ordinary work.

Existing structure helps an agent do useful work

Imagine two collections of customer information.

One contains consistent customer IDs, dated notes, and a clear relationship between a conversation and an account. The other contains names typed differently across several unrelated documents.

An agent can attempt to work with either collection. With the second, it also has to guess whether two similar names refer to the same person.

You can improve the model’s instructions, but the data problem remains. A plausible guess may be wrong, and the mistake can be difficult to notice when the result reads fluently.

Software that preserves clear relationships makes a useful contribution before the agent does anything. It reduces the amount of interpretation needed to answer the question.

This is ordinary application design. The presence of an agent gives us another reason to care about it.

I would rather an app expose a reliable account identifier than rely on an elaborate prompt to reconstruct one from display names. When the information is genuinely uncertain, I want that uncertainty to remain visible in the result.

A small interface can expose a larger capability

An application can provide commands and APIs alongside its graphical interface.

A command-line tool might list records in a structured format. An API might let a client read a particular project. A protocol such as MCP provides a way for applications to expose tools and other context to an AI application.

These interfaces don’t guarantee that an agent will use the product correctly. They give it a more explicit way to discover and invoke capabilities than guessing at a sequence of clicks.

The design still matters. A command named “process” with several ambiguous options is hard to use. A command that describes the action, requires the relevant record ID, and returns a clear result is easier to evaluate.

I would start by exposing a small number of useful operations. Reading records is an understandable first step. Adding the ability to modify them should follow a clear need and appropriate permissions.

There is no benefit in making every internal function callable just because agents exist. An application should decide which operations it can safely offer as part of its public behavior.

Reliable operations matter more when they are combined

A person using an app can notice something strange and stop.

An agent may continue through several operations before a person sees the result. That makes clear success and failure especially valuable.

Suppose a workflow creates a customer record, schedules a reminder, and writes a note. If creating the customer fails, the later steps should not quietly attach themselves to another customer with a similar name.

An operation needs to say what happened in terms the next step can use. Did it succeed? Which record did it create? Did it change anything before reporting an error?

Retries introduce another issue. If a request times out, the caller may not know whether the operation completed. Repeating it can create a duplicate unless the system has a way to recognize the same intended operation.

Stripe’s idempotent requests offer a concrete example of addressing repeated requests. The general design concern also applies to much smaller tools, even when their implementation is different.

Good behavior under interruption makes a tool easier to compose with other tools. It also helps a human developer troubleshoot the same workflow.

Human review needs something concrete to review

Putting a confirmation button at the end of an agent workflow doesn’t automatically make it understandable.

If the screen says “Update completed plan?”, I still need to know which plan and what will change.

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

The amount of review should fit the consequences. Reading a note and deleting a project deserve different treatment.

A tool can help by supporting a preview before a change. It can also keep a history that shows what happened and offer a practical way to undo appropriate operations.

These features are useful without AI. An agent gives them more occasions to be useful, because it can prepare larger changes more quickly than a person entering each one manually.

I would spend time making those changes easy to inspect before adding more autonomy.

Good interfaces still help people think

There is a version of the future where every app becomes a blank box waiting for a prompt.

I don’t want that for every task.

Sometimes I need to see the information to know what I want. A calendar shows an overcrowded day before I can formulate the right question about it. A well-designed editor makes the document’s structure visible while I work.

Asking for a summary is different from looking around and noticing something the summary wasn’t instructed to include.

A good interface offers useful defaults and immediate feedback. It can make common work faster than explaining the same request in a sentence. It also gives me a place to verify the outcome of delegated work.

Agents and interfaces can complement each other. I can ask an agent to prepare a change, inspect it visually, and make a small adjustment myself.

I would evaluate the combination by how well it supports the task. Replacing a convenient button with a conversation can make the software worse, even if the conversation is technically impressive.

Faster implementation leaves room for neglected details

There is another reason agents can improve software. They can make it cheaper to address work that kept losing its place in the schedule.

Think about the export that loses formatting, the search result that gives no context, or the keyboard shortcut that works on one screen and fails on the next.

Each issue can seem too small to justify interrupting a larger feature. Together, they shape whether the app feels dependable.

If an agent reduces the time required to investigate and implement a fix, I can spend more attention on these details. I still need to notice the problem and decide how the behavior should change.

This is where I would like some of the productivity gain to go. I don’t need every saved hour to become a new feature.

But delegation needs care here too. A broad instruction to “polish the app” can produce visual changes that make the interface less consistent. A concrete problem gives the agent a useful boundary. Explain what happens, describe the desired behavior, and check it in the actual workflow.

Good software gives you something worth customizing

A dependable existing tool can also be a starting point for a personal workflow.

Perhaps a local app already handles files well, but I want a different naming convention. Perhaps a working open source product needs one additional field to match a small team’s work.

An agent can help make those adjustments when the source and license permit them. Starting from a functioning product preserves useful behavior that I would otherwise need to rediscover.

I’ve explored this possibility in Liquid Software, where software comes with source that its owner can understand and adapt.

That doesn’t mean any codebase becomes effortless to change. A tangled project with unclear behavior remains difficult to modify safely. Tests and understandable structure help establish what the customization should preserve.

For someone learning to make these changes, knowing the fundamentals still pays off. My free JavaScript course provides a foundation for understanding what an agent changes in a JavaScript application. You need enough understanding to recognize whether the result matches the problem you asked it to solve.

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 according to the way their team works. A researcher might need an export formatted for a particular tool. A person managing family documents might want a local search that understands their folder structure.

An agent can help connect existing capabilities around those needs. The original app doesn’t have to add every variation to its main interface.

This can keep general-purpose software simpler while allowing personal workflows around it. It works best when the boundaries are clear. People need to know where their data lives and which component is responsible when something fails.

I would prefer a small extension that I understand over a chain of integrations whose behavior I cannot explain. More connected tools can mean more useful work, but they can also make recovery harder.

Start with a task you can observe from beginning to end. Keep the result small enough to inspect. Expand only after it proves useful during ordinary work.

Extending an app you already use

I would choose an app that already does a job well and look at the work around that job.

Where do I copy information elsewhere? Which repeated operation makes me leave the app? Which question requires opening several screens and assembling the answer myself?

Then I would look for the smallest suitable interface. A file export might be enough. A command-line tool might fit a local workflow. An API or MCP tool could make sense when an agent needs to interact with the app directly.

For this site, I’ve already described publishing Markdown versions of posts. That is a small example of exposing existing content in a form another tool can use. The original content remains useful to readers, and the additional representation supports another way to access it.

For a writable tool, I would begin with read-only access and a clear output. I’d add changes only when I could show what the agent planned to do and recover from an interruption.

The useful measure would be a task I no longer have to repeat manually, with results I can still understand. If the agent adds more supervision than the task required, I would keep the original workflow and improve the tool before trying again.

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