Making Software Agents Can Use

This post adapts a short talk I gave to the Agentic Builders Collective in Singapore. The talk began with a belief: a business can lose work to a product that gives agents a clearer way to use it.

That belief points to product design. Agents can do knowledge work when they have the required context, access, and tools. Product state, permissions, commands, and errors shape whether the agent finishes the workflow.

Agents already use software

An agent reads product state, calls APIs, runs commands, writes updates, handles errors, and chooses whether it has enough information for the next step. The agent experiences every missing field and ambiguous error in the workflow.

A product that reduces handoffs can help an agent complete more work. That creates a product-design opportunity for teams that make the state, permissions, and next actions easy to inspect.

The founder problem

I am an ideas person, so I start many things. I run dozens of agents across projects, businesses, and parts of my life. Some are OpenClaw agents; others run in Claude Code or Codex sessions. The agents can do the work, yet I remain the dispatcher.

The hard part was constant context loading and dispatching. I loaded the project context, selected the next task, and judged whether the action was safe for each session.

I wanted a product that could hold this context and give each agent a useful next step. That problem led me to build Atoll.

I went looking for a project management tool

I found task lists, comments, and APIs. I still needed a member model and workflow that an external agent could use with its own runtime. Agents also needed enough context to choose work and enough feedback to recover from an error.

I started building a small project management tool for myself. The board UI handled the human view. The API and CLI gave an agent paths to inspect work, update it, and report progress.

Why the CLI became the test

A UI gives a person controls. An API gives software requests. A CLI lets an agent use the same workspace where it reads files, changes code, and reports back.

A CLI exposes practical questions. Can the agent read current state? Can it preview or limit a risky write? Does it use the intended account and project? Does an error explain the next safe step?

Atoll documents those paths through commands such as atoll heartbeat --json, atoll issue list --open --json, and atoll issue update. A skill file can add the product concepts, permissions, and recovery rules that a command alone cannot provide.

The practical audit

Choose one important workflow. Ask the agent to inspect the current state, take the intended action, respect permissions, report progress, and recover when the product rejects a request.

If a person must interpret a hidden UI state, remember context from a previous session, or paste instructions from another tool, record that handoff. It marks a product surface that needs clearer data or a safer command.

How Atoll gives agents useful context

Atoll connects goals, KPIs, initiatives, milestones, and issues. A goal states the desired outcome. A KPI records the measure and target. An initiative describes the work expected to move the KPI. Teams plan and execute it through milestones and issues.

A relationship between those records gives an agent a reason for the task, its expected impact, and the work attached to it. KPI snapshots can record a value and attribute it to an initiative or issue. The heartbeat returns context according to the caller's access and saved heartbeat policy.

The compact heartbeat prioritizes actionable signals, direct attention, and a recommended action when Atoll has enough evidence. The full heartbeat remains available when an agent needs assigned work, goal detail, or project context.

Agents expose workflow gaps

Give an agent the tools, access, and skill guidance it needs to inspect state before it writes. The agent can follow documented commands, preserve the right project and account, and report an error with enough detail for a human to decide what happens next.

Agents surface confusing state because they do not fill in missing context from memory. That feedback can improve the product for people: clearer state, safer permissions, better errors, and fewer handoffs.

Two useful resources

clig.dev offers practical guidance for predictable, composable command-line tools. Use it to review the CLI workflow for your product.

CLI-Anything explores generated command-line interfaces for agent-operated software. It provides a useful reference for thinking about commands as product surfaces.

Choose one workflow, read its product docs, and ask an agent to list each handoff. The list gives you a concrete starting point for a more useful CLI.