Rocketlane - Project Governing Agent (Agentic UX)
I explored how an AI agent should behave when a simple project instruction triggers a cascading chain of governance conflicts.
The user gives Nitro one outcome “Complete CLM implementation.” From there, the agent navigates the project hierarchy, identifies blockers, involves the right people, and continues once the required information or approval becomes available.
The experience focuses on a central idea: an agent can own progress toward a goal without assuming unlimited authority.
- Company
- Rocketlane
- Project
- Design contract
- Scope
- Product thinking, agentic UX, interaction design, visual design, and prototyping
- Output
- Interactive prototype and walkthrough
The challenge
A milestone may have an incomplete task. That task may depend on another task. Resolving one conflict can immediately reveal the next.
The user should not have to inspect this hierarchy manually or repeatedly tell the agent to continue.
The product needed to answer four questions clearly:
What is Nitro trying to complete?
What is currently blocking it?
Who owns the information or decision required next?
What will happen once that dependency is resolved?
The challenge was to keep the original goal visible while surfacing only the conflict that currently required attention.
Creating the product structure
I organised the experience around one continuous execution loop:
Goal → Inspect → Act → Detect conflict → Involve owner → Wait → Observe → Resume
The Agent and Canvas work as two parts of the same system. The Agent explains Nitro’s intent, progress, blockers, requests, and completion.
The Canvas shows the underlying project truth: tasks, owners, time entries, dependencies, evidence, and status changes.
Every meaningful Agent action produces a corresponding change in the Canvas, without both surfaces repeating the same information.
The first conflict
Nitro begins with the instruction:
“Complete CLM implementation.”
While traversing Business Go Live and Customer UAT, it reaches UAT Validation and finds that Sarah Mitchell has logged 0h.
The task cannot be completed without an actual time entry. Nitro understands what is missing, but it cannot invent a value owned by Sarah.
Instead, it explains the blocker and offers the smallest necessary intervention: request the missing time.
Once the request is sent, the task moves into a durable waiting state. The goal remains active, the current owner is visible, and the request can be traced or resent.
When Sarah later logs 6.5h in the project, Nitro observes the change, verifies the task, and resumes automatically.
The project manager does not need to say “continue.”
The second conflict
Resolving UAT Validation reveals another governance boundary.
The Go-Live GO/No GO review requires formal UAT Sign-off.
Nitro can confirm that validation is complete, actual time has been logged, and the required evidence is available. However, readiness does not give Nitro the authority to approve the sign-off.
The resolved time-entry conflict compresses into history, while UAT Sign-off becomes the active focus.
Nitro presents the evidence and requests approval from an authorised stakeholder. It then waits without abandoning the original goal.
Once sign-off arrives, Nitro verifies the decision and resolves the remaining chain:
UAT Sign-off → Go-Live GO/No GO review → Business Go Live → CLM Implementation
Designing the experience
The product contains several levels of project information, but the user should only need to answer one question at any moment:
What decision does Nitro need from me now?
To support this, resolved work becomes quieter while the active conflict expands.
The original goal remains visible throughout the run. Waiting is treated as a valid execution state rather than a failure or indefinite thinking state.
Motion reinforces causality: the project changes first, Nitro observes the change, and execution resumes.
Completion is deliberately calm. There is no celebration screen only a completed project and a clear record of how Nitro reached the outcome.
The outcome
The prototype demonstrates an agent that can pursue a complex project outcome while respecting the boundaries of human knowledge and authority.
Nitro receives the goal once, navigates the project structure, identifies the active blocker, involves the correct person, waits without losing context, and resumes when project truth changes.
The experience can be summarised as:
The goal persists.
The active conflict receives focus.
Human authority remains explicit.
Resolved work compresses.
Nitro continues when it is safe to do so.
What I learned
Trustworthy agentic UX is not about removing people from the process.
It is about understanding when human input is necessary, making that responsibility clear, and allowing the agent to continue independently once the dependency is resolved.
If I continued this work, I would test the model with longer conflict chains, simultaneous blockers, rejected requests, changing policies, and situations where the user takes ownership back from Nitro.
A trustworthy agent does not make complexity disappear.
It holds the complexity, surfaces the decision that matters now, and knows when it is safe to continue.