Dual control: why every button is also a tool

A common pattern is to build the product for a human first, then add an API for automation later, often for different use cases than the UI. The API tends to lag the UI. It exposes whatever one integration needed at the time, not the full set of things the UI can do. Its validation rules drift out of sync with the UI's rules, because different people maintain the two at different times, for different reasons.

That drift is where problems show up. A UI action might enforce a business rule: a required field, a permission check, a rate limit. The bolt-on API never got the same rule, because nobody was thinking about the API when the UI rule was added. An automated call can then do something the UI would have blocked. Not because it was designed to bypass the rule, but because the rule only ever lived in one of the two places.

Dual control is the discipline of building the UI action and its tool twin at the same time. One design decision with two entry points, rather than a UI decision and a separate API decision later. In practice, when a new action is added to SalesCrew, such as contact_create, cadence_advance or approval_approve, the MCP tool schema and the UI form are designed together. They share the same validation and the same access checks. They produce the same recorded effect, whether the caller is a person clicking a button or a token calling the tool.

This is more work up front than building a UI and letting the API catch up. Every new action means two entry points instead of one, tested against the same expectations. The payoff grows with the number of automated actions. There is no separate, less-scrutinized automation path. An agent calling a tool is held to exactly the rules a person using the interface would be. Not a looser set that happened to go unpatched.

It also means the access-control model is built once. SalesCrew's three-axis scope, channel, Upwork profile and area, and its default policy table, which decides what runs unattended and what waits for review, apply to a tool call the same way they apply to the matching UI click. The tool and the UI action are one permission check evaluated for two callers. They are not two systems that happen to agree today and might not tomorrow.

With a handful of automated actions, keeping a bolt-on API in sync with the UI by hand is annoying but survivable. With 145 registered tools, close to one for every UI action, it would not be. Dual control has to be a rule, not a suggestion. At that scale, a gap between the two surfaces is not a rare edge case. It is near-certain across that many actions if the two are maintained separately.

The other benefit is that the manual path never breaks when automation is turned off. The UI action was never secondary to the tool. A customer who disables every agent and every token still has the full product through the interface, exactly as it worked before any automation existed. That guarantee, that turning automation off costs nothing in capability, only follows from building the two paths as one decision from the start.