A goal
What is the person actually trying to protect? For Fluxy, that is arriving on time — not simply finding a route.
FLUXY / BUILDING IN PUBLIC
When does an app actually need an agent?
I didn’t start by designing an agent. I started by asking whether the product needed one at all. Fluxy became a way to test that question in public: what can a commuting system do usefully without making the passenger supervise every step?
01 / THE QUESTION
An agent only earns its place when a normal interface starts to fall short.
Some problems need a clearer screen, a better default or one less decision. I used Fluxy to look for the point where a system can prepare useful work on its own — without quietly taking over the journey.
Context
The agent watches the things that can change the plan: delays, connections, time and the passenger’s constraints.
A decision
It chooses whether to stay quiet, prepare an option or ask the person to decide. That boundary is the product.
A visible action
Every intervention explains what changed, what Fluxy recommends and what remains under human control.
02 / THE FIRST VERSION
The first version was too helpful.
I initially treated autonomy as a feature: detect a disruption, suggest a better route, move on. That looked efficient on the whiteboard. In practice, it made the system feel like it was making decisions before it had understood the passenger’s goal.
So I stopped asking “what can the agent automate?” and started asking “what is the smallest useful intervention?” That change gave the prototype a much clearer shape.
03 / THE RULES
Rules before screens.
These are the decisions that keep an autonomous system useful without making it opaque or overbearing.
Protect the goal
The system optimises for the passenger’s arrival goal, not for a route in isolation.
Be useful before being visible
Fluxy watches the context and prepares the next useful option before asking for attention.
Keep the decision explicit
It can explain and recommend. Consequential changes stay behind a clear, human confirmation.
05 / BUILD NOTES
Five things I am learning while building the agent.
Short, technical notes from the parts that usually disappear behind the interface: policy, APIs, tooling and failure.
When does an app actually need an agent?
Not every hard workflow needs autonomy. I look for a goal that persists, context that keeps changing and decisions that are expensive to repeat.
- Rules can cover predictable paths.
- Chat can explain a state.
- An agent earns its place when it can watch, prepare and hand control back.
Rules before prompts.
The useful part of an agent is not the prompt. It is the boundary around the prompt: when the system acts, waits or asks.
- Act when the goal is safe and the context is fresh.
- Wait when a recommendation is useful but reversible.
- Ask when money, identity or a major journey change is involved.
Design the API around intent, not screens.
A prototype becomes more believable when its interface has a contract. I model the goal, constraints, permissions and proposed action before drawing the final surface.
- Structured input: goal, constraints and user authority.
- Structured output: recommendation, reason, confidence and next action.
- A trace for every tool call, so the decision can be inspected later.
The CLI is part of the product.
If I cannot run the same scenario twice, inspect the trace and replay the failure, I do not really understand what I designed.
- Fixtures make edge cases repeatable.
- A trace makes hidden decisions visible.
- A small command surface turns a vague demo into a testable system.
Failure is a state, not an exception.
Agents operate with stale context, uncertain tools and incomplete permissions. The interface has to make uncertainty legible before it becomes a surprise.
- Show what the system knows and what it does not.
- Keep consequential actions reversible or explicitly approved.
- Hand off to a person with the context intact, not with a blank error.