We kept changing what the word ‘Secrets’ meant.
At first, that looked like a frontend problem.
Farstax had customer-managed values that coding agents needed while working in a workspace. As the product grew an application layer, we also had values that genuinely belonged to one hosted application and should not leak into another one. Separating those things was clearly the right direction.
So we made secrets application-scoped.
That was tidy.
It was also wrong for some of the ordinary things a person was trying to do.
The architecture was more precise than the product
The application boundary solved a real problem.
If application A has a database password, application B should not receive it merely because both applications happen to live in the same workspace. Farstax's own internal configuration should not receive it either. An application is a meaningful boundary for application-owned secrets.
The mistake was turning that truth into a rule for every customer-managed secret.
Once we did that, a workspace owner could need to register a hosted application before giving their coding agent a value it needed for ordinary work in the workspace.
That is the sort of requirement that can sound reasonable when you know the architecture.
It sounds much stranger when you are the person using the product.
‘I want my agent to have this credential while it works here’ had quietly become ‘first tell Farstax which hosted application owns it’.
Sometimes there was no honest answer to the second question.
We had made an internal distinction into a customer prerequisite
The correction was to admit that there are two useful scopes.
Workspace secrets belong to the workspace as a place where delegated work happens. They are available to coding-agent work in that workspace without requiring an application to exist.
Application secrets belong to a particular hosted application. They stay attached to that application and can be managed without turning them into Agent Bridge's own service configuration.
An application can refine a workspace-wide value where that is deliberate. It does not have to exist before the workspace can have useful configuration of its own.
That sounds obvious written down.
It was not obvious enough in the first implementation.
Then the interface exposed the disagreement again
After we restored the workspace-level concept, the UI still had to carry both worlds.
For a while, compatibility work intended to preserve Workspace secrets could replace the newer Application secrets panel in the rendered page. Both pieces existed. One could make the other unreachable.
Again, it was tempting to see this as a rendering bug.
The rendering bug was real, but the reason it was so easy to create was more interesting: we had two concepts with similar names, overlapping jobs and different ownership rules arriving at different points in the product's history.
The interface was where that history became visible.
We ended up keeping the two surfaces separate rather than asking one generic Secrets page to guess which model the user meant.
UI friction can be architecture feedback
I have a bad habit of treating an awkward screen as evidence that the screen needs more explanation.
Add a subtitle. Add a selector. Add a help note. Add a little badge saying which scope is active.
Sometimes that is exactly right.
Sometimes every extra sentence is the interface trying to compensate for a product model that is still unclear.
The useful question became: if we removed all our internal nouns, what is the person actually trying to control?
A workspace is the top-level place where they delegate work.
Applications are things inside that workspace which can have their own runtime, route and configuration.
Some secrets naturally follow the workspace. Some naturally follow an application.
Once the hierarchy is stated that way, asking the interface to expose it becomes much less heroic.
The nouns matter more as agents do more
This is not just information architecture.
A human can often work around a fuzzy product boundary. They read the labels, inspect the page, remember which box did what last time and correct themselves when the result looks odd.
An agent needs the boundary to be mechanically true.
If a value belongs to a workspace, the runtime should not make its availability depend on which directory the agent happens to be working in. If a value belongs to an application, another application should not inherit it by accident. If a customer value is not Farstax configuration, it should not become part of the platform service environment just because that is a convenient place to inject it.
Better labels cannot rescue the wrong ownership model.
The UI and the runtime have to agree about the noun.
We are still learning the application model
The same distinction was becoming visible elsewhere in the product.
I do not think that means we have found the final hierarchy.
It means the product is giving us better evidence about where the hierarchy needs to be explicit.
Domains have become application-aware. Application removal has to understand which application is serving traffic. Application secrets need a real application target. Workspace secrets should remain useful even when none of that exists yet.
Those distinctions are becoming clearer because we have had to live through the cases where they were not.
Sometimes moving the page is the right symptom
There is an instinct to freeze navigation and terminology early because repeated UI movement feels like product indecision.
It can be.
But I would rather move a page while the model is still being learnt than polish a stable interface around the wrong idea.
The mistake was not that Secrets changed.
The mistake was briefly assuming every secret had to fit the newest architectural layer because that layer was cleaner.
The useful result is not a better Secrets page in isolation. It is a product model where a technical founder can say ‘this belongs to my workspace’ or ‘this belongs to this application’, and Farstax can make that distinction real without asking them to understand how we arrived there.
When an interface keeps becoming awkward, I am trying to remember to ask one question before redesigning it again:
Is the page confused, or are we?