Agent work often spans terminal panes, local hook output, PR context, and hand-written notes. FactionOS gives the team a product vocabulary for mission status and review context.
Engineering teams
Shared review context for local agent work.
Give operators a mission picture for parallel agent work while keeping prompts, paths, credentials, and review state local by default.
Engineering teams need a common way to understand what agents are doing, where review is needed, and which local signals support a change.
- Focusreview
The problem
Where the work loses its shape.
Before and after
What changes with an operating picture.
Mission status
Before
Status is inferred from terminal scrollback, chat updates, or stale PR notes.
With FactionOS
A local cockpit can summarize active lanes, mission posture, and review checkpoints.
Cockpit visibility is product runtime behavior.
Review context
Before
Reviewers ask what changed, which tool ran, and why an agent moved to the next step.
With FactionOS
File, tool, validation, approval, and lifecycle signals stay attached to the mission.
Signals should stay narrow and avoid raw secrets, full source, or broad path dumps.
Parallel work
Before
Planner, builder, and reviewer agents drift because ownership is not visible.
With FactionOS
Lanes, subagent lineage, and checkpoints give operators a shared map.
Lineage is event context, not a promise that every external provider is supported.
Failure handling
Before
Broken hooks or validation gaps become invisible until someone audits manually.
With FactionOS
Diagnostics and validation state surface as visible local product signals.
Diagnostics copy must expose failure states without leaking sensitive output.
Surface mapping
Which surface does the job.
Availability and guardrail columns keep local, optional, and outbound clearly separated.
| Capability | Surface | Availability | Guardrail |
|---|---|---|---|
| Cockpit | apps/web cockpitMission lanes, agent roster, review state, and structured timeline context. | local | Hosted workspace and team account workflows are separate. |
| Hooks | hook event pipelinePrompt lifecycle, tool activity, validation, and file-touch signals become local events. | local | No default upload of prompt bodies, credentials, or source files. |
| War Room | optional collaborationA team-readable mission view can exist only when deliberately configured. | optional | War Room collaboration is optional and separate from the local baseline. |
Operator proof
How this path shows up in the cockpit.
Review example
Review checkpoint row
A mission row can show owner, status, validation state, and next review action.
Evidence Useful when a reviewer needs context before approving a risky local change.
Review rows keep next action and validation state visible.
Boundary
Local privacy reminder
Role copy keeps prompt bodies, local paths, credentials, and source code out of public previews.
Evidence Useful when adopting agent visibility in privacy-sensitive repositories.
Local-first behavior is the baseline unless a later integration is explicit.
Boundaries
What stays true for this role.
- separateAccount
Hosted organization, SSO, role management, and team account workflows are separate product concerns.
- operatorReview
Review surfaces describe operator checkpoints; local tools still control execution.
Team path
Inspect the surface map, then open the guided demo.
Use product and features pages to compare the local cockpit and review surfaces, or open the external demo to inspect the flow.
The zero-install demo is a guided preview and stays separate from local sessions. Hosted team work remains a separate product concern.