Making autonomous work easier to supervise
An independent product concept exploring how a developer-consultant can supervise multiple agents, understand progress, and locate the source of a failure without deciphering long technical logs.
Status: Early discovery and product definition
- Project type
- Independent concept
- First user
- Developer-consultant and entrepreneur
- Research origin
- A developer friend who runs agents continuously for research, product management, project management, software creation, lead generation, and general business operations
- Status
- Early discovery and product definition
On this page
Overview
The idea for Nexus came from a developer-consultant who uses agents throughout his business. Different agents research opportunities, support product and project management, build concepts, find leads, and handle operational work. When something goes wrong, the available record is often a long technical log. It may show every event without helping him understand which decision or subtask caused the failure.
I am starting with that real workflow rather than designing a generic control center for an invented operations persona. The first goal is to understand how he currently notices a problem, investigates it, and decides whether to retry, intervene, or stop the work. From there, I can test whether a more visual model of plans, tasks, handoffs, and failures helps him act faster.
How I made sense of it
The central design question
How might we help one person supervise multiple agents and locate the meaningful point of failure without requiring them to reconstruct the work from raw logs?
The initial product hypothesis is that an operator needs two connected levels of information:
- A concise operational view of what is running, waiting, blocked, completed, or at risk.
- A task-level explanation that traces a failure to the responsible agent, decision, input, tool call, or handoff.
Raw logs may remain available as evidence, but they should not be the primary interface for routine supervision.
The first scenario
I’m not designing the platform overview first. I’m starting with one scenario from the real user:
- 01
The user assigns or approves a goal.
- 02
A lead agent creates a plan and delegates subtasks.
- 03
Multiple agents work in parallel or sequence.
- 04
One subagent produces a weak result, uses the wrong input, loses context, or fails a tool call.
- 05
The parent task continues, stops, or produces a questionable result.
- 06
The user receives a useful signal.
- 07
The user identifies the source and consequence of the failure.
- 08
The user inspects the relevant evidence.
- 09
The user retries, edits instructions, reassigns, pauses, approves, or rolls back.
- 10
The system records what changed.
Controls to explore, not assume
- Status and progress
- Plan and task hierarchy
- Agent and subagent ownership
- Tools and data accessed
- Inputs, outputs, and dependencies
- Confidence or uncertainty, only if it can be defined honestly
- Approval gates
- Permissions and limits
- Pause, stop, and resume
- Retry from a selected step
- Reassignment
- Escalation
- Rollback or recovery
- Audit history
Each control has to answer a real user need. I’m avoiding placing every possible control on one screen.
Validation and status
The work is at the discovery and product-definition stage. The initial evidence is one real user’s report that it is difficult to understand what agents are doing and where a subagent’s work went wrong.
The plan is to interview and test prototypes with that original user before broadening to technical operations teams.
Nexus isn’t trying to solve agent governance broadly. It is one carefully researched supervisory problem, and I expect the concept to change after contact with a real user. I don’t have results on diagnosis time yet, so this page doesn’t claim any.