Illustrated Chief workflow from the asklog film.
I kept opening another coding-agent terminal and then becoming the coordinator for all of them. One session needed a decision, another had finished a change, and a third was still working from an instruction I had already changed.
I built asklog, so this is a maker's account of the design. The useful part is the set of boundaries behind the workflow: separate working copies, durable instructions, and evidence before calling a result complete.
Start with one request and explicit boundaries
The workflow is simple to describe. I give Chief a request. It divides the work into tasks and starts Claude Code or Codex workers. Each worker gets its own copy of the repository. Chief follows the results and brings the decisions back to me.
That does not make every task independent. A schema change and the client that consumes it have a dependency. Two workers changing the same abstraction can produce individually plausible changes that do not fit together. I want the task brief to say what the worker owns, what evidence it should return, and what it must ask about.
If you build this yourself, start with a brief like this:
Goal: make reconnect recover the session list.
Own: the reconnect handler and its browser journey.
Constraints: no protocol change; preserve existing credentials.
Evidence: reproduce the disconnect, reconnect, and show the session.
Ask: if the fix requires changing credential renewal.
The important part is that the scope and the decision boundary are written down before work starts.
Give each worker a working copy
asklog uses Git worktrees for worker copies. They share the repository's object storage while keeping checked-out files and branches separate. That prevents one worker's uncommitted file edits from silently becoming another worker's starting point.
Isolation ends at the working copy. It does not create independent database servers, cloud accounts, ports or production environments. If two tasks use one external resource, the brief still has to name who owns it. I also would not describe a worktree as a security sandbox: code running as the same operating-system user needs additional confinement for that.
A merge remains an integration event. Separate branches can still disagree about interfaces or behavior. A clean merge is evidence about text compatibility, not proof that the combined product works.
A terminal window is a client
The terminal engine has two processes underneath it. One owns the PTYs and their running shells. The other owns client connections. The desktop and phone attach to those sessions.
This matters when the desktop window closes or updates. Closing the viewer should not be the event that ends a worker's shell. It also means a restart is not one generic case. If the PTY process is still alive, a new connection layer can adopt it. If the host reboots, the original process is gone. Restoring screen history and starting a new shell is recovery, not uninterrupted execution.
The phone is a client of the running host. It does not move the agents onto the phone. The host still has to be awake and reachable.
Submitted is not acknowledged
Sending a new instruction is another place where the easy implementation lies. A successful write proves that bytes were accepted somewhere. It does not prove that the intended worker read the instruction.
The delivery model keeps those states separate: pending, submitting, submitted, acknowledged, or uncertain. If delivery becomes uncertain after an interruption, blindly sending the same instruction again can duplicate work. A durable inbox gives the next session a record to inspect and acknowledge.
The same principle applies to a decision. A later progress message should not bury an unanswered question. Keep the question as a record that remains open until an answer closes it, and reject stale answers when the question has changed.
What broke in the session layer
One concrete failure was protocol skew during daemon adoption. A newer connection layer sent an optional request field to an older PTY process. The older schema stripped the unknown field and returned success. The terminal started in the right directory, but the session was missing its intended workspace association.
The lesson was not that optional fields are always compatible. The question is whether silently ignoring the field is acceptable. If it changes what the user asked for, the old process needs an explicit refusal or a compatible upgrade path.
Another failure was cold terminal recovery. A serialized screen can contain the modes a dead TUI left behind: mouse reporting, bracketed paste, focus reporting or a hidden cursor. Replaying those modes into a fresh shell leaves the shell looking or behaving incorrectly. Replay needs an explicit mode reset after the saved history.
Neither defect is found by checking that a worker returned a confident paragraph. The test has to reach the real lifecycle transition.
Check the result outside the worker's prose
A worker saying 'done' is a report. It is not the repository state. Verification needs to inspect the actual branch and head, the reviewable change, and the checks required for that task. No check suite is not a passing check suite.
For user-facing bugs I want the end-to-end reproduction first, followed by the same journey after the fix. For state-machine work I also want the interrupted path: the action committed but the response disappeared, the process restarted halfway through delivery, or a stale decision answer arrived after a new question.
The practical benefit of a Chief is having one place to follow those tasks and decisions. It does not remove the need to define what success means or to inspect the evidence.
Where this fits
asklog brings the normal Claude Code and Codex terminals into desktop workspaces and lets a phone reach the same sessions. Chief coordinates workers around them. You use your own agent accounts.
It is paid software. The three-day trial requires a card, excludes Chief and renews monthly unless canceled. Monthly and lifetime include Chief. The 20% lifetime offer ends November 5, 2026 at 23:59 IST.
The short film and downloads are here: https://asklog.ai/?ref=dev-article-20261102
Top comments (0)