The agent’s own experience
Continue with the supported agent’s native interaction alongside your existing terminal and editor.
BatonX / Developer CLI
Keep the agent. Add the enterprise boundary.
Developers start a BatonX session for an authorised project and continue working with a supported native agent. BatonX applies the organisation’s controls around the session.
Developer continuity
Your terminal. Your editor. A governed agent session.
Changes can remain visible in the developer’s existing editor. BatonX is not a replacement terminal or IDE; it is the secure session boundary around the agent.
A containerised session
Run the supported agent in a containerised BatonX session without a separate agent installation on the developer host.
A governed model route
Model requests from the session pass through BatonX LLM Gateway before reaching an approved provider endpoint.
One entry point. Your agent, governed.
The agent runs inside the approved session boundary while its native interaction stays familiar.
Agent support
Select an agent to explore the illustration.
Start through BatonX
Conceptual session command
batonx run <agent>Local setup
Local setup requires BatonX CLI and the container runtime approved by your organisation.
Keep the native experience
Governed agent session
Claude Codebatonx run claude
The native interaction stays familiar. Organisational policy may block an action or require approval within the session.
The model request has a controlled path.
Within a governed session, BatonX LLM Gateway applies the organisation’s model-access policy. Provider credentials remain outside the agent runtime; request, usage and cost metadata support operational visibility.
Governed model access
A coding agent in a containerised BatonX session sends model requests through BatonX LLM Gateway. The gateway applies model-access policy before an approved cloud, private or internal endpoint is reached. Policy and request metadata contribute to audit evidence.
Containerised agent
Authorised project session
BatonX LLM Gateway
Model policy · credential separation
Approved model
Cloud, private or internal endpoint
Audit evidencePolicy decisions · request metadata · usage
Customer-managed deployment keeps BatonX under your control. Context required by an approved external model may still leave the customer environment.
A clear path from project to developer decision.
For isolated workspace modes, select the authorised project, work in the governed session and review the changes before applying or discarding them.
Developer CLI session lifecycle
A developer selects a project, BatonX resolves policy and creates an isolated session, the agent works, then the developer reviews and applies or discards changes.
Select project
Resolve policy
Isolated session
Agent works
Review changes
Apply or discard
Review/apply/discard flow shown for isolated workspace modes. Direct Mode has different review semantics.
Choose the workspace boundary deliberately.
BatonX is designed to support controlled workspace options selected by organisational policy:
| Workspace mode | Working state | Review and acceptance | Trade-off |
|---|---|---|---|
| Git Worktree Mode | Separate working state with clear review and discard semantics. | Review the session diff, then apply or discard changes before they reach the original working copy. | The session has its own working state. Open that workspace in the editor to follow changes during the session. |
| Controlled Copy Mode | An isolated copy when a worktree is not suitable. | Review changes in the isolated copy before bringing accepted changes back to the original project. | The separate copy can diverge from the original working state; review must account for that difference. |
| Direct Mount ModeExplicit opt-in | Live editor visibility for approved cases, with explicit trade-offs and opt-in controls. | Changes reach the mounted project directly. There is no separate apply/discard safety gate. | Requires explicit opt-in and organisational approval. Review changes through the existing source-control workflow. |
The final decision stays with the developer.
In isolated workspace modes, inspect the diff and choose what reaches the working copy. Direct Mount requires review in the live project; its changes have already reached the mounted workspace.
Commit, push and merge remain the developer’s responsibility. Human review does not weaken mandatory organisation controls.
Apply
Accept reviewed session changes into the working copy.
Discard
Reject isolated session changes without accepting them into the original working copy.
See whether BatonX fits your developer workflow.
Evaluate the supported agent, workspace mode, review point and approved model route against a representative project.
Request a technical pilot