Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@bat list all running sessions and show what each one is waiting on"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Understand the project. Discuss the problem. Decide with the PM.
English · 繁體中文 · Website · Install and start · Progress
Better Agent Dashboard keeps project state, PM discussions and decisions in one workspace. Start with the live Overview, open a problem's original record, and discuss it with the PM without rebuilding the context. Review the proposed update and explicitly adopt it; requirements, work and delivery keep their own evidence.
Open the interactive Dashboard demo.
Explore the actual shared interface with synthetic, read-only project data: search work,
expand requirements, inspect delivery evidence and browse sessions. The demo also links to
the v1.3 workflow preview, which simulates the proposed start, follow-up and decision flow.
Neither example connects to a BAT host or model.
The real Start work panel is on main and needs a configured BAT host and a bound repository.
Merged main can start a bound Work item with work.start and that panel, read the attempt's fixed Result, and show a read-only Result section in the Board's Work inspector (E03 part A).
Not merged: a second instruction to the same Work (P5), adopt-and-start in one step (P6), reading current changes and per-commit diffs on request (E03 part B), work profiles and readiness (E01), MCP/API loop parity (E10), and the closed loop end to end; no real BAT start, follow-up or Result has been observed, and nothing here is installed or live-tested.
Actual shared UI · synthetic demonstration data · merged-main preview · capture source.
The Web and Tauri desktop apps share one interface and one Python backend. You keep using Better Agent Terminal (BAT) for your own coding. Windows Fleet manages local connections and startup. Connector keeps project history, permissions and operations consistent across the Dashboard, CLI and MCP.
Development preview. The screenshots come from merged
mainat265026d4(October 16, 2026, through #205). Nothing shown here is installed or live-tested. The progress report separates branch, merged, installed and live-tested status. Match a successful package to its exact source; screenshots and CI do not establish native or live acceptance.
Your question | View and workflow |
Where does the project stand? | Overview shows the live goal, accepted requirements, blockers, open decisions and Recently decided history. Needs attention lists each record with one Discuss action. Unread sources stay Unknown; complete empty lists say None recorded. Saved reports retain their fixed snapshots. |
What needs a decision? | Open a record and Discuss with PM. Discussions opens with its context chip and automatic title. Search threads, save a note, and review a proposed update. Context, Inputs and Plan open in Discussion info. An adopted discussion can offer an authorized, editable Resolve issue step; reported resolution remains unassessed. |
What is this work meant to satisfy? | Requirements shows adopted requirements with work, PR, Acceptance and Deploy columns. Expand a row for criteria and work; open the inspector for evidence. Unchanged refreshes keep rows and focus stable. |
What is still unresolved? | Issues & changes keeps risks, issues, actions, changes and decisions in a filterable register with original timelines and named maintenance findings. |
Which dates changed? | Schedule compares recorded baseline, forecast and actual dates on a labelled axis. Missing dates stay unknown. |
What could a dependency change affect? | Dependencies shows pinned inventories, evidence and bounded impact in a matrix or graph. |
What are the agents using? | Agents keeps sourced usage, rows and daily trends on one consistent read, with reported quota windows. Unavailable data stays unknown. |
What should happen next? | Board offers search, requirement and agent filters, plus the shared work inspector. When the workspace can start work, that inspector includes Start work and, for a started attempt, a read-only Result section. Content approval, requirement acceptance, merge and deployment remain separate. |
What needs a recorded response? | Open Governance or Follow-ups from Issues & changes. Meeting threads have a Meeting tab in Discussion info. Saved outcomes keep their original sources. |
What may maintenance do? | Dependencies holds Release baselines and Maintenance policy. Preview a release source before registration; policy adoption and enabled repair limits remain explicit. |
Where are the work tools? | Requirements → More actions opens quality, evidence, specification, package, handoff and issue publication tools; Board → More actions opens Work batches. |
What happened in that session? | Session keeps the conversation and results together. Authorized managed controls are available; manual BAT sessions remain read-only. |
These are views of the same project, with secondary tools available on demand. The current scope distinguishes the merged workspace from the full PM v1.2 backlog. The progress report lists work still in review.
Related MCP server: HT MCP Server
Understand the state. Create a workspace from the workspace switcher and start an Idea in Discussions. For member sign-in and password reset, record the goal and exclusions; use Overview once a plan is adopted.
Find one problem. Open its record in Requirements, Issues & changes or Schedule. Inspect the linked evidence and what is still unknown.
Discuss with PM. Use that record's Discuss action. Its source chip and title follow you into Discussions. Save a note, then ask the PM for a proposed update.
Review and adopt. Prepare the PM-owned Git worktree at a fixed revision. Check sources, proposed wording, retained requirements and open questions. An authorized workspace owner explicitly adopts the reviewed update.
Follow the evidence. Inspect the adopted requirements and their work in Requirements, Board and Session. Verification, requirement acceptance, PR merge and deployment each need their own record.
A discussion does not automatically adopt a plan; adoption does not start work or resolve its source issue. After adoption, an authorized person can explicitly report the issue resolved; this does not accept a requirement. Policy-bounded delivery and maintenance remain available through the project's secondary tools. Step-by-step PM guide.
More views from the same synthetic project | Screenshot |
Issues & changes | |
Schedule | |
Dependencies | |
Board | |
Session |
Use the desktop workflow on main. Choose a successful platform job, match its source commit and validation records, then download that run's artifact. GitHub may require sign-in, and artifacts expire. These are validation packages, not a stable signed update channel.
Entry | Package / local features | Boundary |
Windows x64 |
| Unsigned validation package. Windows Fleet manages connections and BAT startup. |
macOS Apple Silicon / Intel |
| Ad-hoc signing; Windows Fleet is not ported to Mac. |
Linux |
| External-central native credentials remain memory-only; persistent native vault is excluded. |
Browser | Open the central's | Same project data and UI; no browser-native Fleet or credential vault. |
The desktop package prepares a matching Python runtime, private background central, data and personal identity.
First use opens Get ready to work → 1. Connect BAT. Paste BAT’s connection URL, check the Host ID, then Verify and save host. After success, choose View sessions. Repository binding and verification commands are optional collapsed steps; configure them when the work needs them.
Joining an existing central is an explicit advanced option. A failed connection never creates a replacement project database. Closing the Dashboard window does not stop central work.
PM analysis has separate runtime requirements. The current bounded analysis paths run on a configured Linux central or eligible Linux BAT host, using the pinned PM Codex runtime and confinement described in the guide. A Windows or Mac client can use those remote capabilities; its local desktop installation does not provide native Windows/Mac PM execution. PM analysis support is distinct from a general coding CLI adapter.
Installation and first use · Windows guide and resources · Recovery and upgrades
flowchart TB
Web[Web Dashboard] --> Central[Python Connector / Task Service]
Desktop[Tauri Dashboard] --> Central
API[CLI / MCP / agent integrations] --> Central
Desktop --> Fleet[Windows Fleet: connections and startup]
Fleet --> Routes[SSH routes / selected BAT profiles]
Routes --> BAT[BAT hosts and workspaces]
Human[Your BAT desktop / mobile] --> BAT
Central --> Journal[Plans / evidence / permissions / operations]
Central --> BAT
BAT --> Manual[Human resources: Connector read-only]
BAT --> Managed[Agent-owned sessions and worktrees]
Managed --> Delivery[Fixed commits / PR / merge / deployment]
Delivery --> CentralConnector is the authority. Python owns project state, policy, dispatch and the durable journal. Tauri owns local windows, credentials and transport; it does not duplicate the business backend.
Work stays on the chosen host. Same-host continuation can use a fixed checkpoint. Cross-host code synchronization uses an explicitly bound GitHub repository and published commits.
Windows Fleet remains a distinct layer. Select background connections, BAT profiles and Dashboard startup independently. Route/readiness checks, Tailscale entry, configured central bootstrap and explicit Rust/PowerShell migration preserve ownership.
Clients share state. Web and Tauri use desktop/src; drafts and reading positions remain local to each client. Hermes, Grokbot and other MCP/CLI clients use their own principals and scopes.
Status | Scope |
Merged baseline | Desktop/central foundation; PM discussions and plan adoption; engineering packages and bounded dispatch; verification, requirement acceptance and dependency evidence; policy-bounded maintenance repairs; BAT proposals/Follow-up; AHP read-only observation. #132 adds central Overview, discussion context and renames, register, Schedule, Dependencies and daily resource buckets. #134 adds adopted goals, recent decisions and the guided close of a resolved issue. |
Merged workspace | Overview with saved reports; Discussions with Discussion info (Context, Inputs, Plan, Meeting); Requirements and its inspector; Issues & changes with Governance and Follow-ups; Schedule; Dependencies with Release baselines and Maintenance policy; Agents; Board; Session; first-run BAT setup from one Connection URL. Merged into |
Remaining PM v1.2 | General native coding adapter, AHP create-own/write support, remaining document views and presentations, wider CLI support, remote usage collection and delivery-efficiency attribution. |
Local Codex/Claude usage collection exists; the redesign's Agents view adds sourced daily trends and reported quota windows. Remote collection and delivery-efficiency attribution remain planned. Missing usage stays unknown; observed tokens, API price estimates and subscription quota are different measures. No usage-driven model policy is active. Progress and priorities.
Formal signing, Mac notarization, production update channels and Linux persistent native credential storage are outside the agreed delivery. Real-environment acceptance belongs to the owner and has not been claimed as passed. The full PM v1.2 plan remains the scope; M4 is one milestone.
Human sessions and worktrees remain read-only through Connector. Unknown resources need original creation evidence before managed recovery. Reading another session never transfers control of it.
A lost reply does not prove an action failed. Recover the original operation and key; uncertain work keeps its evidence and reservations. Current permissions and source availability are checked before effects. Connector policy complements host accounts and confinement; it is not an operating-system sandbox.
Security model · Resource policy · Operations
Need | Start here |
Use the product | |
Understand progress | |
Continue development | Documentation handoff · Adopted plan · Architecture decisions |
Integrate an agent | Agent skills · API · Protocol |
Follow results |
uv sync --locked --extra dev
uv run ruff check .
pytest-disktmp uv run pytest -q
cd desktop
npm ci
npm run build:all
npm test
npm run test:uiUse a disk-backed pytest temporary directory and remove it after the run. pytest-disktmp is the development host wrapper; if unavailable, supply a unique disk-backed --basetemp. Never use /dev/shm or another tmpfs. Backend changes also require the Python 3.10 suite. Follow CONTRIBUTING and AGENTS.md.
Edit the shared UI in desktop/src and regenerate browser assets. The public website is generated from repository source. Tests use mock BAT/providers and temporary repositories, without live-host writes.
An unofficial MIT-licensed companion to BAT, not affiliated with or endorsed by its authors. BAT is by TonyQ and contributors. Selected organization and interaction patterns reference Project Hub; no Hub importer or runtime dependency is included. See the adoption review.
This server cannot be deployed
Develop, manage, and debug Railway projects, services, and deployments from within agents.
Read a project's prompts, logs and agents, and send new work to the agent on your own machines.
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Docs for agent-manager, the terminal UI that runs AI coding agents as live tmux sessions.
