How Agent Interfaces Are Changing Software Development and the Way We Work

For years, if I thought I might need to work, I brought my laptop. A meeting, a conference, a few hours away from home: the computer went into the bag. Work happened wherever I could open it.

Recently, I have started leaving it at home more often. It stays on, with coding agents working across repositories and connections to the services I am building. From my phone, I can check progress, ask questions, redirect a task, or review a proposed change.

A laptop running agents at home can be doing more useful work than the same laptop asleep in my backpack.

That change in my own routine has clarified something about the software we are building at StateSet. The next generation of software should be built with AI and designed for AI agents to operate. The agent needs a reliable way to understand the system, inspect its current state, and take permitted actions inside it.

Once those connections exist, development and operations start to work differently. So does the role of the person directing them.

Build the service and the agent interface

When we build an order management system, we are building the application alongside the interfaces through which agents can use it. That includes a REST API and a Model Context Protocol, or MCP, server.

MCP gives AI applications a standardized way to connect to external capabilities. A server can expose tools an agent can invoke and resources an application can retrieve as context. It provides a common structure for those interactions; the service still has to implement the underlying behavior.

For an order management system, useful capabilities might include retrieving an order, inspecting a job, reading the active configuration, or proposing a configuration update. The quality of those operations matters. An agent needs to know what a tool does, what inputs it accepts, what happened when it ran, and what to do when it fails.

I think of this as building the conduit into the software. The same service can have a browser interface for an operator, a terminal interface for a developer, and a structured interface for an agent. Each should work with the same business rules and permissions.

This also changes the relationship between the coding agent and the product. The agent helps build a service, then becomes a user of the capabilities that service exposes. It can inspect the consequences of its work and use that information when proposing the next improvement.

Configuration becomes a conversation

The first practical use is configuration. Consider a request such as, “Change the order synchronization interval from one hour to 90 minutes.”

A system designed for that interaction should let the agent retrieve the current setting, identify the requested change, and show what will be different. After any required approval, the service can validate and apply it. The operator should be able to see which environment changed and whether the new setting took effect.

Structured configuration, whether stored as JSON, YAML, or database records, makes the settings explicit. Version history adds another useful capability: an agent can compare the current configuration with an earlier one and help restore a previous version.

We have to build that version history and make the effects of each change clear. Restoring a configuration changes how the system behaves going forward; it does not reverse transactions already completed.

With that foundation, the conversation can be about the behavior we want. I can describe the operational change, review the proposal, and check the result without having to remember where every setting lives.

Reporting starts with an operational question

The second use is reporting and analytics. Once an agent has authorized access to operational data, I can ask questions that cross the boundaries of a fixed dashboard.

How many orders did we process this month? Which customer conversations produced completed outcomes? Where did a workflow skip an action because of a configuration rule?

That last question is especially useful. A count tells me what happened. Connecting the count to the configuration helps explain why it happened. If a rule deliberately excluded a category of orders, I want to distinguish that from a processing failure.

The service has to expose enough information to make the distinction. The agent needs clear definitions, the relevant records, and the rules that governed their processing. A useful report should preserve its date range and filters, identify missing data, and let someone trace a conclusion back to the underlying evidence.

The agent can then turn that analysis into something useful for the team: a report, an explanation of an exception, or a proposed change to investigate. The value comes from connecting a business question to the actual behavior of the system.

Debugging gains access to live state

The third use may be the most valuable while building: debugging a service through its current operational state.

An agent looking at source code can reason about how a system is supposed to behave. Access to recent jobs, logs, and configuration gives it evidence of how the system is behaving now.

For example, I want to ask, “Show me the last ten jobs in the order management system. Which failed, and what do they have in common?” A useful answer would identify the affected jobs, show the relevant errors, and explain the likely cause. If the evidence is incomplete, it should say what still needs to be checked.

That creates a shorter path between observing a problem and investigating it. The agent can follow a job into its logs, compare the active configuration with the expected one, and locate the relevant code. A proposed fix can include both the evidence behind the diagnosis and a way to verify the result.

That reduces the amount of context I have to collect and paste into a conversation. The agent can investigate with the system in view.

The terminal becomes a shared workspace

This is also changing the interfaces I want while developing. In one terminal pane, I can work with a coding agent. In another, a terminal user interface, or TUI, can show orders, recent jobs, conversations, or configuration.

The two views serve different purposes. The conversation is useful for explaining intent and asking questions. The TUI provides a persistent view of the state I am watching. If we change how a job is processed, I want to see the next run without reconstructing the whole picture from chat messages.

In a terminal emulator such as Ghostty, I can bring the coding agent and the operational view into the same workspace.

As those interfaces develop together, they can expose gaps in the service. If neither the person nor the agent can tell why an order was skipped, we may need a clearer explanation in the underlying system. Improving that explanation can help the TUI, the agent, and the operator using the browser.

Better interfaces improve the development cycle

This is the development loop I find exciting. We build a service and expose useful ways to inspect it. Agents use those interfaces, encounter limitations, and help us identify what is missing. We review and test the resulting improvements, then make the new capabilities available for the next round of work.

An investigation might reveal that failed jobs have poor error messages. The next change could add structured failure reasons, expose them through an MCP tool, and display them in the TUI. The next investigation starts with better evidence.

Multiple agents can contribute across repositories, but the work still needs coordination. Shared interfaces need clear contracts. Changes need tests that check the intended behavior. Someone needs to decide whether an additional feature solves a real problem and whether the proposed implementation is ready to ship.

What matters is how quickly we can turn a problem in the running system into an improvement we can test and ship. Better access to the service can help an agent produce a more informed proposal, and a more informative proposal can be easier for a person to review.

Over time, the product becomes easier to understand and change because each improvement can also strengthen the tools used to maintain it.

The phone becomes a place to direct work

This brings me back to leaving the laptop at home. In the setup I am describing, the phone is the interface. Agents run on a computer or server that remains online and connected to the services they need.

A private network such as Tailscale can connect those devices. Its SSH capabilities support remote access governed by access policies. The network connection gives me a route to the machine; the agent interfaces give that connection something useful to do.

From a mobile terminal, I can ask what finished, inspect an issue, or give an agent its next task. A request that needs my judgment can come back with the proposed action and supporting evidence. I can approve a straightforward change there and leave more involved review for a larger screen.

That is a meaningful change in how work fits into a day. At a conference or between meetings, I can check the state of something without first setting up a workspace. The agents can continue their assigned work while I am away from the keyboard.

The quality of that experience depends on how well the work is packaged for review. A phone is useful for a clear decision. It is much less useful for deciphering an unexplained change across hundreds of files. Better summaries, visible results, and explicit choices make remote direction practical.

What we are building toward at StateSet

At StateSet, I want this approach to shape the commerce systems we are building. An order management system should expose the information needed to explain an order. A warehouse workflow should make its current state and exceptions inspectable. An agent working with customer conversations should be able to understand which actions were taken and which rules determined the outcome.

Those expectations belong in the product design from the beginning. They influence the data we preserve, the operations we expose, and the way we handle errors. They also influence how the product will be developed, because the agents helping us build it will depend on the same clarity.

My bet is that the quality of a product’s agent interface will become an important part of its value. A service that can clearly explain its state and accept well-defined actions is easier to connect to other work. As agents become more capable, those connections give them more useful ways to contribute.

That is where I am putting my effort: building the services, building the access into them, and improving the cycle through which we develop and operate them.

I still spend plenty of time at a computer. But I am increasingly building software that lets useful work continue when I step away from it.