Product thinking · · 7 min read
Why GrantTap is a control center for local agents
The task stays visible while providers, sessions, and computers change. Here is the product decision behind that design.
A coding agent can do useful work for minutes or hours while you are elsewhere. The hard part is rarely starting one more session. It is knowing which work needs a decision, which computer holds it, and whether a tool was actually allowed and used.
GrantTap treats the Task as the unit a person follows. An Execution is one provider session doing that work. A child agent belongs inside its execution. This lets the visible task survive a provider change or a new native session without inventing a new user request.
See the work before you interrupt it
The Now screen puts Needs You before routine activity. A useful status names the current provider, computer, workspace, last meaningful event, and delivery state. It does not turn every tool call into a notification. The phone and Watch are for a glance, a bounded decision, and a short continuation; the coding runtime remains on the computer.
If a computer goes offline, the task should say so. A message queued for delivery is different from one accepted by a provider, and both differ from a tested code change. We preserve those distinctions because a reassuring green dot can be more misleading than an explicit unknown.
Keep authority close to the action
GrantTap coordinates Claude Code and Codex as primary integrations; Cursor is Beta and other providers have narrower documented behavior. Each provider retains its own session and controls. Mesh policy can allow, ask, or deny a capability, but a chosen policy is not proof that every computer enforced it. A host must report its observed state.
The relay transports encrypted envelopes. Provider credentials and the local coding environment stay on the computer. This architecture is a choice about where work and authority live, not a promise that every external model service is private: provider traffic still follows that provider's own terms.
Make handoffs legible
A supported handoff carries bounded task and git facts, relevant decisions, blockers, and an explicit target. It does not copy hidden reasoning across providers. Repository identity and resource claims help people notice overlapping work; a receipt shows whether the next execution accepted the transfer. Remote-start support still depends on the provider and target host.
The measure of success is simple: after stepping away, can you tell what happened, what remains unknown, and where your next decision belongs? GrantTap is being built around that question, with product status shown as carefully as product ambition.
A phone should reduce uncertainty
The first useful question away from a desk is often simple: does this work need me now? A feed of every internal agent step would make that harder to answer. GrantTap's control-center idea begins with a stable Task and a concise status: the current execution, computer, recent meaningful event, pending decision, and delivery state. A person can then choose to inspect the full context on the computer when the decision demands it.
This also sets a limit on notifications. An agent reading a file is not necessarily news. A permission request, failed delivery, blocked handoff, or completed verification may be. The product should not infer urgency from raw event volume. It needs to distinguish routine progress from a moment when human judgment changes what happens next. A useful glance is one that lets a person safely return to their day when no action is needed.
Keep the unit of work stable
A provider session can stop for ordinary reasons: an app restarts, a context window changes, or the work moves to another computer. The user's Task remains. GrantTap groups successive executions under that visible unit and keeps child agents nested where they ran. This avoids a common coordination error: treating a delegated investigation or a new native session as an unrelated request, then losing the decision trail that explains why the work exists.
The stable identity does not mean every provider can be resumed identically. Provider support and remote-start paths differ. A Task can keep its objective and history while a particular route is unavailable. The interface must say which continuation was requested, which was accepted, and which remains only possible in principle. Continuity is valuable precisely when it survives those limitations honestly rather than pretending every execution is interchangeable.
Authority belongs to the real action
A person may choose an allow, ask, or deny rule for a capability, but the meaningful security question is where that rule is enforced. The local computer performs the coding action and must apply controls on the paths it owns. A policy displayed on a phone is not sufficient evidence that an unobserved provider-native route was blocked. GrantTap therefore treats selected policy, host application, and observed invocation as separate facts.
This separation also improves everyday debugging. If a tool is listed but cannot initialize, the person needs the host's reported state, not another generic approval button. If an action was allowed but never invoked, usage should remain unknown or absent according to observation, not be counted as consumption. Honest boundaries let the control center be useful without implying broader policy coverage than the computer can enforce.
Local work still uses external services
The coding environment and provider credentials remain on the computer, while GrantTap's relay carries encrypted envelopes between authorized devices. That choice limits what the relay is asked to know. It does not change the data flow between a coding provider and its model service. When choosing a workflow, people should read the provider's own privacy and retention terms for model traffic. ‘Local control’ describes the authority and tool location, not a blanket promise that no data leaves the computer.
It is equally important to distinguish a connection from a result. The relay can carry a message while the target provider is stopped. A computer can be online while an integration is not ready. A provider can accept a prompt without producing a verified code change. The control center should show these transitions as separate states so a remote user never has to infer success from connectivity alone.
A day in the intended workflow
Suppose you start a coding Task on a laptop and leave for a meeting. On the phone, you see that the agent needs permission for one specific command. The request names the Task, computer, capability, and proposed action. You can approve, deny, or wait until you can inspect more context. Later, a delivery receipt shows that the decision reached the host; a subsequent event may show an invocation and a tested result. Each line answers a different question.
If the laptop becomes unreachable halfway through, the Task still exists and reports the interruption. When it returns, you can continue through a supported path or choose an explicit handoff to another execution. The product should not silently reroute to an arbitrary machine. The generated illustrations above depict this relationship conceptually; the Now screenshot below uses deterministic sample data. Your own evidence comes from the live Task, its host state, and the verified outcome.
What success would look like
Success is not a dashboard with the most counters. It is a person knowing what the agent is doing, what they are authorized to decide, and how to check the result. When the app says something is unknown, that should be actionable: perhaps the host is offline, the provider cannot report usage, or a tool has not been initialized. A clear unknown is preferable to an invented zero or a green completion badge unsupported by evidence.
GrantTap's product boundary is deliberately Personal and centered on local coding agents. Claude Code and Codex are primary paths, Cursor is Beta, and other behavior is described only where implemented. The control center should become more capable by making the existing Task, execution, capability, and usage surfaces more precise. Its design earns trust when the person can follow a decision to the computer that applied it and the work that followed.
