Making Software Agents Can Use

This post is adapted from a short talk I gave for the Agentic Builders Collective in Singapore. The talk started with a simple belief: almost any business can be challenged by another business that gives agents a better way to use its software.

That sounds like a claim about AI, but it is really a claim about product design. Agents are already good enough to do a large amount of knowledge work when they have the right context and the right tools. The failure mode is usually not that the model is too weak. The failure mode is that the product gives the agent a bad experience.

Agents are software users now

Agents are already software users. They read your product state, call your APIs, run your commands, write updates, hit errors, and decide whether the next step is clear enough to continue.

If an agent can complete the work in one product with fewer handoffs than it can in another, work starts moving toward the easier product. That is a competitive risk for incumbents. It is also the opportunity: a new product can win by being the place where agents can actually finish the job.

The founder problem

I am an ideas person. That is useful, but it also means I start too many things. I have dozens of agents running different projects, businesses, and parts of my life. Some are OpenClaw agents. Some are Claude Code or Codex sessions. The agents are capable, but I was still the dispatcher.

The hard part was not explaining a strategy deck before every task. The hard part was constant context loading and dispatching. I had to tell each agent what to do next, remind it which project it was in, point it at the relevant work, and decide which next action was safe.

It felt like working with brilliant coworkers who had no initiative unless I stood next to them and pointed at the next action. That is the problem that led me to build Atoll.

I went looking for a project management tool

I tried the obvious tools. The problem was not that they lacked task lists, comments, or APIs. The problem was that agents were still treated as second-class users.

Some tools wanted me to use their agent runtime. I wanted to bring my own agents. Other tools exposed APIs, but the agent still could not see enough context to choose useful work or finish the workflow without me routing every step.

So I started building a simple project management tool for myself. Then I realized the important part was not the board UI. If a human could see work, change work, comment on work, or report a bug, an agent needed a path to do the same thing.

Why the CLI became the test

A UI is what a person clicks. An API is what software calls. A CLI is a command an agent can run in the same workspace where it is already reading files, changing code, and reporting back.

A CLI does not magically make a product agent-ready, but it reveals the hard parts quickly. Can the agent see current state? Can it preview a risky write before applying it? Does the command keep the agent in the right account and project? When something fails, does the error say what to try next?

Those details matter because agents are stateless by default. They do not carry your product intuition between sessions unless you give it to them. Good commands, good errors, and good skill files become part of the product experience.

The practical audit

Pick one important workflow in your product. Now ask whether an agent can finish it without a human sitting beside it.

The agent needs a way to inspect the current state, take the intended action, stay inside the right permissions, preview risky changes, report progress, and recover when the product says no. If one of those steps requires a human to interpret the UI, remember hidden context, or paste instructions from another tool, that is where the agent experience is breaking.

How Atoll makes agents more autonomous

Atoll is built around the strategy chain that normally lives in a founder's head, a planning doc, and a task board at the same time: goals, KPIs, initiatives, milestones, and issues.

A goal says what the business is trying to achieve. A KPI shows whether the goal is moving. An initiative is the bet that should move the KPI. Milestones and issues turn that bet into actual work. That chain matters because it lets an agent understand why a task exists, not only that a task exists.

The KPI layer is dynamic. KPIs can be updated manually, through API snapshots, or by connected systems. When a KPI is stale, off pace, or moving because of a specific initiative, that becomes useful context for the agent. The agent can ask: which work is most likely to move the number we care about?

The heartbeat is the agent's briefing. It gives the agent current goals, KPI pace, assigned work, blocked issues, stalled initiatives, board state, and signals. Instead of waking up to an empty prompt, the agent wakes up to the operational state of the business.

Agents can become perfect users

If you give agents the right tools, the right access, and the right skill files, they do not need to discover your product the way a human does. They do not need onboarding calls, repeated explanations, or a week of absorbing your opinions. The product can teach them directly.

A good skill file can encode your product's concepts, workflows, defaults, and sharp edges. It can tell the agent how to authenticate, which commands are safe to run first, how to inspect state before writing, and how to recover from common errors. The agent does not have to infer your product philosophy from screenshots or docs scattered across the web.

This makes agents unusually honest product users. They do not politely work around confusing state. They do not remember what you told them last week. They either have the context and affordances needed to finish the work, or they get stuck. That bluntness is useful.

That is why designing for agents is not separate from designing for humans. You are making the product state clearer, the permissions safer, the errors more useful, and the workflows easier to complete. Agents benefit first because they are less forgiving. Humans benefit next because the product became easier to reason about.

Two useful resources

clig.dev is a practical guide to building command-line tools that are predictable, composable, and humane. Put it in your repo and ask an agent to make a concrete plan for the CLI your product should expose.

CLI-Anything is a research project exploring how agents can operate software through generated command-line interfaces. It is useful if you want to think about the broader direction: agents need software surfaces they can operate reliably, not only pages they can look at.

The practical next step is simple: choose one workflow, give your agent the relevant product docs, add clig.dev, and ask it where a CLI would let future agents finish the work with fewer handoffs.