Why agent work needs a cockpit

AI coding tools can move quickly, but their work often arrives through narrow views: terminal scrollback, editor diffs, task notes, and one-off status messages. Each view is useful. None of them is enough by itself when several sessions are running or when a human needs to recover the thread after an interruption.

A cockpit gives that work a shared operating surface.

The cockpit is not the executor

FactionOS is not trying to replace the agent, the editor, or the terminal. The cockpit is the place where work becomes readable: which session is active, which task is next, which file changed, which command failed, and where a human decision is needed.

That distinction keeps the product honest. The agent still performs the work in its own toolchain. The cockpit helps a developer see and steer that work. It does not imply file, git, terminal, container, remote, or inbound-command execution by the website or by a hidden hosted control plane.

The product overview and how it works page describe that separation as mission control for local agent sessions, not as a new remote executor.

Why the battlefield model helps

The battlefield metaphor is useful when it stays concrete. A session can have a position, a status, an owner, a recent event trail, and a relationship to other active work. Those concepts make coordination easier without pretending the system has perfect knowledge.

The first public website phase prepares the static product story around that model. Later pages can show more of the battlefield and cockpit experience, but the publishing foundation needs to land first so the product narrative has a durable place to grow.

Better human handoffs

Good agent workflows need handoffs that survive context switches. A cockpit can make those handoffs visible by separating facts from speculation: tasks completed, tasks waiting, commands run, validation status, and notes that a human can audit.

Different users care about those handoffs for different reasons. The engineering teams page frames them around team review. The power users page frames them around parallel personal workflows. The shared need is legible state, not automatic trust.

What should stay visible

A useful cockpit keeps the following facts close to the surface:

• Which session is active and what it is trying to finish.
• Which files, tasks, and validations changed recently.
• Which failures need attention instead of disappearing into scrollback.
• Which claims remain out of scope until they have implementation and evidence.

That is the product direction: less hidden state, more legible work, and clear boundaries around what is known.