> For the complete documentation index, see [llms.txt](https://faction-os.gitbook.io/faction-os-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://faction-os.gitbook.io/faction-os-docs/public-website/src/content/blog/why-agent-work-needs-a-cockpit.md). # 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 an operator see and steer that work. It does not imply file, git, terminal, container, remote, or inbound-command execution by the website or by a hosted control plane. The [product overview](https://github.com/AI-with-Apex-VIP/factionos/tree/main/product/README.md) and [how it works page](https://github.com/AI-with-Apex-VIP/factionos/tree/main/how-it-works/README.md) 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 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](https://github.com/AI-with-Apex-VIP/factionos/tree/main/use-cases/engineering-teams/README.md) frames them around team review. The [power users page](https://github.com/AI-with-Apex-VIP/factionos/tree/main/use-cases/power-users/README.md) 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 capabilities remain separate until they have implementation and evidence. That is the product direction: less invisible state, more legible work, and clear boundaries around what is known. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://faction-os.gitbook.io/faction-os-docs/public-website/src/content/blog/why-agent-work-needs-a-cockpit.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.