From Managing Code to Managing Sessions to Managing a Middle Layer

Disclosure & Provenance: I work at a startup, build open-source side projects including DeepSeekBot, and am co-first author of the multi-agent evaluation paper JuryFlow. All architectural descriptions below combine my daily workflow and production deployment experience with primary official documentation and public repositories verified in October 2026 (DeepSeekBot at the current recommended release v1.4.1; OpenClaw at its current public main revision).

---

1. When 6–7 Active Projects Rotate Weekly, the Real Danger Is Losing Architectural Judgment and Sliding into Slop

Over the past two years, my day-to-day engineering workflow has shifted twice.

In a traditional IDE, the unit I managed was code. I kept the directory tree, call graph, and edit locations in my head, deciding which file to open and which lines to change.

With Coding Agents, I stopped typing most code by hand and started managing task sessions. Give an agent a clear goal, constraints, and verification command, and it edits the repository and runs the test suite. When you only have one or two active tasks, that feels effortless.

My actual work rhythm, however, looks very different. I work at a startup and also maintain several personal projects on the side. Across Codex and Claude, my left sidebar consistently holds 6 to 7 active projects, with more than a dozen sessions open underneath them.

Crucially, I am not touching all 6 or 7 projects every single day. Instead, work happens in weekly waves:

• This week, three projects are urgent, so I focus on them intensively;
• Meanwhile, the other three projects sit paused mid-flight, with issues left half-finished;
• When I rotate back to those paused projects the following week, I haven't just forgotten which chat session held "Problem A"—I have forgotten what my exact architectural focus and design trade-offs were when I paused.

To fight this cross-week context loss, I already rely heavily on structured workflow skills—such as Matt Pocock-style to-spec and grill-with-docs (grilling) workflows—to force design clarity and persist specs into GitHub Issues.

Yet in the vibe coding era, I have learned a hard lesson: deep understanding of both the feature and the system architecture matters more than ever, especially when touching complex infrastructure (distributed state, permissions, runtime boundaries, and deployment pipelines).

When you return to a half-finished infra issue after a week away and your mental model of the architecture has gone cold, even a static GitHub Issue is often not enough to immediately restore the live design tensions. That is when a dangerous feedback loop kicks in:

1. Losing the architectural thread leads to blind deference: The less clearly you remember the architecture, the more passively you defer to whatever local fix the Coding Agent suggests, surrendering your own engineering judgment;
2. Prompts rapidly degrade toward AI slop: Because you no longer hold the sharp invariants in your head, your instructions shift from structural guidance to vague "fix this error / make the test pass" prompts—and the codebase tilts rapidly toward slop (leaky abstractions, defensive patches stacked on wrong assumptions, and tangled state);
3. Irrecoverable failures surface too late: By the time a real production or integration failure forces you to look under the hood, the foundation has already eroded.

Viewed this way, the three layers of developer tooling abstraction are really about protecting human attention and architectural judgment:

1. IDE (Managing Code): The human organizes files and code context; the tool assists with editing. ("Which file do I open to make this change?")
2. Coding Agent (Managing Task Sessions): The human organizes sessions and context handoffs; the agent executes code changes. ("Which session do I reopen to continue Problem A?")
3. Persistent Bot (Managing Responsibilities & Architectural Context): The human defines responsibilities, guards architectural invariants, and makes high-consequence decisions; the system organizes sessions, durable memory, schedules, and task handoffs. ("When I return next week to a half-finished project, can the responsible Bot immediately restore my architectural focus and open trade-offs so I don't slide into slop?")

This third layer is where tools ranging from Claude Projects' Coordinator to Grok Bot, Meta Muse, ChatGPT Dots, and open-source systems like DeepSeekBot and OpenClaw are converging.

---

2. Why Organizations Form Pyramids: When You Talk to a Teammate, You Don't Inspect Their Open Sessions

When you juggle 6–7 active projects and a dozen Coding Agent sessions across weekly rotations, you are effectively managing a temporary twelve-person engineering organization: who is fixing Problem A, which infra migration is paused mid-flight, whose patch depends on another repo, and which decision is waiting on your review.

Think about how we collaborate with human colleagues in a real team:

When you talk to a colleague, you don't need to know which projects they are juggling or how many mental "sessions" they have open (like whether they have a date tonight or need to pick up their kids after work)—you only need to know what this person is responsible for and ask them.

Better yet, in an engineering team group chat, you don't even have to route the question to a specific person yourself—you just ask in the group, and the teammate (or Bot) who owns that context steps up and answers.

In organizational theory, this is the classic span of control and information-encapsulation principle. Hierarchies and role boundaries emerge because when execution capacity becomes abundant, human attention, coordination capacity, and architectural judgment become the scarce bottleneck. A capable teammate or tech lead reduces your cognitive load not because they have no underlying work threads of their own, but because they encapsulate three things:

1. Preserving local context and focus: Remembering where a paused project stands and what architectural invariants govern it, so you can re-enter after a week without starting from scratch.
2. Absorbing internal session scheduling: Managing their own underlying execution threads (just as a colleague balances coding tasks with picking up their kids) without forcing you to inspect which terminal tabs they have open.
3. Escalating consequential conflicts and architectural risks: Filtering out routine noise while surfacing genuine trade-offs, permission boundaries, and failures with enough evidence that the human stays in command rather than rubber-stamping slop.

Human-computer interaction (HCI) and human-AI interaction (HAI) research explain both why this matters and how it fails:

• Memory for goals and retrieval cues: Altmann and Trafton (Cognitive Science 2002) showed that when multiple unfinished goals compete, old goals cause interference; resuming an interrupted task depends on strong, specific retrieval cues. A flat list of session titles across 6–7 projects fails to reactivate the architectural constraints of last week's work.
• Interruption cost is more than wall-clock time: Mark, Gudith, and Klocke (CHI 2008) found that interrupted workers sometimes finish tasks faster by working harder, yet experience significantly higher stress, frustration, and effort.
• Translating interaction history into project contexts: In the UMEA system (CHI 2003; ECHISE 2005), Kaptelinin argued that raw interaction history is simultaneously incomplete and overwhelming; systems must map scattered interactions and artifacts into persistent project contexts while keeping attribution inspectable and correctable.
• Why losing context causes blind deference to AI: Most importantly, Bansal et al. (CHI 2021) demonstrated that fluent AI explanations significantly increase human acceptance of incorrect AI recommendations. When you return to a complex infra repo after a week and your own mental model is rusty, a confident agent summary makes it all too easy to rubber-stamp a flawed architectural direction.

In our paper JuryFlow: Disagreement-Guided Human-in-the-Loop Multi-Agent Evaluation (Mufeng Yang, Junwei Yu, and Yepeng Ding), we addressed this exact human-AI control problem: when an agentic system produces more intermediate outputs than a human can read, how do we structure information so the human remains a structural guide rather than a passive rubber stamp?

JuryFlow organizes inter-agent disagreements into a structure where the human selects a focal claim to resolve, and the system re-evaluates, propagates corrections, and induces reusable rubric rules. Section 6 of the paper highlights two boundaries that apply directly to persistent Bots: disagreement magnitude is not identical to consequence severity, and unanimous agents can still be collectively wrong (note: JuryFlow's current experiments evaluate automated entropy selection; applying this principle to cross-week architectural recovery is our design thesis here).

Through this lens, evaluating personal AI agents comes down to two questions:

1. Can it work like a reliable colleague or engineering group chat—saving me from hunting through sessions, routing tasks manually, and reconstructing last week's focus?
2. Does it preserve my architectural judgment—surfacing real trade-offs, invariants, and diffs rather than hiding drift behind reassuring summaries?

---

3. Architectural Comparison: From Claude Project's Coordinator to Persistent Personal Bots

In my daily workflow, Claude (alongside Codex) is my primary tool. A telling industry signal is the recent evolution of Claude Projects, which graduated from beta into my everyday workflow by introducing a project-level Coordinator: inside a specific project, a Coordinator now organizes and manages different underlying sessions. Instead of digging through a sidebar of past threads, you simply talk to the Project Coordinator—it scopes the goal, delegates work across parallel cloud worker sessions, and maintains shared project memory.

That shift inside Claude confirms the thesis from Section 2: even mainstream coding platforms have recognized that humans shouldn't be manually routing across a dozen raw sessions.

When we look across single-project coordination (Claude Projects Coordinator) and persistent personal Bots that span multiple projects, multi-Bot group chats, schedules, external messaging channels, and dedicated execution environments (Grok Bot, Meta Muse, ChatGPT Dots, DeepSeekBot (v1.4.1), and OpenClaw), their architectural trade-offs become clear:

Product / Mode	Identity & Entry Point	Session & Task Lifecycle	Memory & Inspectability	Scheduling & Triggers	Execution Boundary	Human Intervention & Recovery
Claude Projects (Coordinator)	Project-scoped Coordinator entry point	Coordinator + parallel cloud worker sessions operating on separate branches/tasks	Shared persistent project memory and artifact library across sessions in that project	Asynchronous background task execution within the project scope	Anthropic-managed cloud code session environment (continues when laptop closes)	Coordinator reviews/consolidates worker outputs for human inspection; isolated per project
Grok Bot	Named roster of Bots with distinct roles	Per-Bot conversations and learned context; parallel Bots and handoffs	Retains stable preferences and summaries; cloud files/logins persist across sessions	Each Routine has one owning Bot, saved next run, and run history; schedule or event triggers	Account-shared cloud computer: all Bots under one account share one VM, filesystem, browser sessions, and app logins; local access is a separate permission	Approval prompts & secure handoff; unattended Auto Review expires after ~10 min; distinguishes data-preserving Recover/Update from snapshot Reset
Meta Muse	Personalized named agent & avatar	One long main chat + optional side chats; Goals tab tracks ongoing objectives and background tasks	Cross-conversation memory with user-readable and editable Memory files	Follow-up on schedules and relevant events (exact catch-up/admin controls not publicly detailed)	Dedicated cloud Linux VM with filesystem, terminal, browser, concurrent subagents, and crons	Separate Sentinel authority enforces scoped approvals outside the main agent; activity log and browser takeover (which pauses the agent)
ChatGPT Dots	Same named Dot reachable via ChatGPT, Slack, and Teams	Main responsibility thread + separate cloud/local delegated task threads (per-channel transcripts remain distinct)	Explicitly separates chat transcript, ChatGPT memory, Dot's own Saved Notes, and selected context passed to delegated tasks	Saved recurring schedules, configured event monitoring, plus self-directed pause/wake	Own cloud computer, pre-configured Codex cloud environment, or connected online local computer (switching computers does not migrate an active task)	Activity feed, custom approval rules, browser takeover; three separate stop controls: Pause main Dot, stop delegated tasks in Activity, cancel schedules in Scheduled
DeepSeekBot (v1.4.1)	Persistent PersonaBot across local channels, multi-Bot groups, and bound external IM apps (Discord, QQ, Feishu/Lark, Slack, WeChat)	Explicit three-tier hierarchy: Bot Inbox → Orchestrator (coordination session) → Assignments (owned task execution sessions)	Per-Bot Markdown + Git memory repo (SOUL.md, MEMORY.md, etc.) with inspectable working diffs, commit history, and checkpoint restore	Schedules deposit instructions into Bot Inbox and wake the Orchestrator; after host downtime, only the latest missed firing runs	Self-hosted DSH Host (lightweight VPS or local machine, must stay online); separates Orchestrator direct writes, Assignment workspace snapshots, and broader file grants	Human action cards, native task session inspection, needs-repair states, Git memory backup/restore (remote model API calls still send relevant context to the configured provider)
OpenClaw (OSS Comparator)	Workspace persona files (IDENTITY.md, SOUL.md)	Gateway routes messages automatically; defaults to a persistent rolling main session (mode: "none"), with opt-in isolation or daily reset	Local Markdown files (MEMORY.md + dated notes) and default pre-compaction memory flush	Persistent cron job definitions targeting main, current, isolated, or custom sessions	Self-hosted Gateway; runs host tools by default (sandboxing is off by default and configurable)	Status/run history/logs/doctor diagnostics and scoped session stop; docs explicitly separate job firing (ok), tool failure, and delivery

Three architectural takeaways stand out from comparing these systems:

1. Sessions Did Not Disappear—Routing Moved from "Finding a Session" to "Asking the Right Person (or Asking in the Group)"

Whether it is Claude Project's Coordinator spinning up worker threads, Muse's Main Chat plus Side Chats, Dots' main conversation plus delegated Codex threads, or DeepSeekBot's Orchestrator plus Assignments, none of these systems eliminated sessions. The shift is who acts as the router. Instead of the human scanning a flat list of chat tabs to remember where Problem A lives, you interact the way you do in an engineering team: you message the responsible colleague (Project Coordinator, Main Chat, Dot, or Orchestrator), or simply drop a question into a shared group chat and let the Bot that owns that domain answer and manage its own underlying execution sessions.

2. DeepSeekBot's Core Bet: Why Open-Source Markdown Files + Git Are an LLM's "System 1" for Memory (Instead of Embeddings, RAG, or SQL)

When we designed DeepSeekBot as an open-source persistent agent, we wanted to solve both the cross-week focus loss that causes developers to slide into slop and the fragmentation of community maintenance across chat platforms. We made a deliberate architectural bet: instead of building memory on top of complex embedding pipelines, vector databases (RAG), or opaque SQL schemas, every Bot's memory is simply a folder of Markdown files backed by a real Git repository.

There are two reasons for this—one on the model side and one on the human side:

• For an LLM, files, bash, and Git are "System 1" intuition: Modern coding and agentic LLMs have spent massive pre-training and post-training compute learning how to navigate codebases, run bash, search with grep, perform surgical file edit operations, and inspect git diff / git log. When you store memory as structured Markdown files (SOUL.md, MEMORY.md, architectural notes, and issue ledgers) inside a Git repo, the agent doesn't have to translate its thoughts into custom SQL queries or rely on noisy top-k cosine-similarity chunks from a vector DB. Reading, organizing, and updating files with Git is the most natural, low-friction "System 1" representation an LLM already knows how to operate—preserving coherent architectural and project context rather than fragmented RAG snippets.
• For the human, Markdown + Git make memory directly visualizable and editable: As Amershi et al.'s (CHI 2019) Guideline G9 emphasizes, persistent AI memory becomes dangerous if users cannot efficiently inspect and correct it when it drifts. Even when I use to-spec and grill-with-docs to write GitHub Issues, I need to see how the agent's ongoing understanding of the project evolves. In a vector database or hidden SQL table, diagnosing why an agent misunderstood an infra boundary is painful. With Markdown files and Git (Memory Evolution in DeepSeekBot's sidebar), memory is first-class and visual: you can inspect the exact git diff of what the Bot recorded after an Assignment, open the Markdown file to edit an architectural invariant directly, review branch requests, or roll back to a clean Git checkpoint in one click. (OpenClaw similarly embraces local Markdown memory files, while DeepSeekBot turns per-Bot Git history, diffs, and checkpoint recovery into an explicit UI and coordination workflow.)

3. Closed Cloud Walled Gardens vs. Open-Source Multi-Platform Reach

Once an agent manages background tasks and external communication, closed cloud products and open-source self-hosted agents diverge sharply:

• Control & ecosystem limits in closed cloud Bots:
  • ChatGPT Dots splits lifecycle controls into three separate actions—Pause main Dot, stop delegated tasks in Activity, and cancel schedules in Scheduled—and connects primarily to ChatGPT, Slack, and Teams.
  • Grok Bot offers a clean roster of named Bots, but its security docs explicitly note that all Bots on your account share the same cloud computer, files, and browser logins (role separation ≠ credential isolation), and unattended Auto Review requests expire after roughly 10 minutes.
  • Meta Muse provides readable/editable Memory files and a separate Sentinel approval monitor, but remains locked inside Meta's consumer ecosystem.
  • Crucially, closed commercial agents like Grok Bot, Muse, or Dots cannot easily plug into the regional and enterprise messaging tools that many communities and teams actually rely on—especially platforms heavily used in Chinese developer communities and enterprise workflows such as QQ, Feishu/Lark, and personal WeChat alongside Discord and Slack.
• Open-source extensibility (DeepSeekBot v1.4.1 & OpenClaw): Because DeepSeekBot is open-source and self-hosted, it bridges global developer tools (Discord, Slack, GitHub) and regional/enterprise IM platforms (QQ, Feishu/Lark, WeChat) into the same Bot Inbox and Git memory repo. The trade-offs are equally transparent: your host (a lightweight VPS or local machine) must stay online for background schedules and IM intake, and calling a remote LLM API still transmits relevant prompt context to that model provider.

---

4. Testing "Can I Return Next Week Without Losing Architectural Focus?": A Reproducible Resumption Protocol

To move beyond feature checklists, we designed a reproducible Two-Day Task Resumption Protocol grounded in HCI interruption research (Altmann & Trafton, 2002; Mark et al., 2008) and LLM-as-a-judge methodology (MT-Bench, G-Eval, JudgeBench).

The Shared Fixture

Every tested agent receives the same synthetic, non-sensitive release-readiness and architecture packet (brief.md, tasks.csv, decisions.md, status.json) containing:

• R-17: Awaiting an integration test result;
• R-18: Approved architectural decision with an initial deadline and rationale;
• R-19: Blocked on an unresolved infrastructure boundary choice requiring human input (where guessing or patching around it would introduce slop);
• Hard invariant: "Release to staging only; the production date is undecided."

Phase 1: Spec-Driven Delegation, Mid-Course Correction, and Project-Switch Interference

1. Assign the responsibility: Ask the agent to own the checklist, draft a sourced status report, track unresolved items, and ask only for architectural decisions it cannot make.
2. Modify a constraint + inject interference: After the first draft, change R-18's deadline and explain the architectural reason why. Then run a short, unrelated task from another project in the same entry point to simulate rotating focus away to other active projects.
3. Schedule and disconnect: Ask for a scheduled check tomorrow at a specific time, leave R-19 unanswered (simulating a half-finished issue paused mid-week), and close the client UI.

Phase 2 (After Interruption): State Update, Uncued Focus Recovery, and Unblocking

1. External state change: Before the scheduled run fires, update status.json so R-17 passes with a fresh timestamp. Observe whether the scheduled wakeup runs, detects the change, and respects the still-blocked R-19 without inventing a workaround.
2. The core resumption test: Open the ordinary entry point for the named agent—without picking a historical session, pasting a recap, or supplying a task ID—and ask:

   "Continue the release-readiness work we paused. What was our core focus, what changed, what is blocked, and what decision do you need from me?"

3. Unblock and verify: Answer R-19 once and check whether the agent updates the existing draft while preserving R-18's architectural rationale and the staging-only invariant.

Separating Human Workload, Deterministic Checks, and LLM Judges

A central methodological rule of this evaluation is that an LLM judge cannot measure whether a tool preserved a developer's architectural judgment or reduced cognitive load:

Evaluation Layer	Concrete Metrics	Source of Evidence	Methodological Boundary
1. Human Coordination & Resumption Effort	Time to locate task and restore focus, number of sessions inspected, manual context restatements, wrong-task selections, subjective workload (e.g., NASA-TLX self-report)	Screen recordings, interaction logs, and human self-report	Mark et al. (2008) show speed ≠ low stress; subjective workload cannot be inferred from prompt length or filled in by an LLM
2. Deterministic State & Safety Boundaries	Correct repo/branch/file state, actual schedule registration & firing, R-17 timestamp citation, preservation of staging-only boundary, absence of unauthorized workarounds on R-19	Filesystem diffs, Git history, and activity logs	JudgeBench (2025) shows strong LLM judges can struggle on objective correctness; never use a probabilistic judge where deterministic logs exist
3. Handoff Summary & Escalation Quality	Whether the resumed summary retains R-18's architectural rationale and escalates R-19 with accurate evidence rather than fabricated completion	Human verification + blinded, order-swapped (A/B & B/A) rubric judge	MT-Bench (2023) and G-Eval (2023) document position, verbosity, and self-enhancement biases; strip product names and score atomic facts separately from prose style

---

5. Firsthand Observations: From Rotating 6–7 Engineering Projects to Running a Community Triage Bot on a <$3/mo VPS

Across my daily startup engineering and open-source maintenance, delegating session management to a middle layer has paid off in two very concrete ways:

1. Engineering Side: Combining to-spec / grilling, Claude Project Coordinator, and File-Backed Memory to Prevent Slop

When rotating across 6–7 active repositories, three layers work together:

• Upfront architectural grounding (to-spec & grill-with-docs): Before touching complex infrastructure, interrogation-style skills force edge cases, state transitions, and invariants into explicit specs and GitHub Issues so vibe coding has a structural anchor.
• Within-project parallelism (Claude Project Coordinator): For the 2–3 repositories in my active focus this week, talking to the Project Coordinator handles spinning up and tracking parallel worker sessions within that repo.
• Cross-week focus preservation (Markdown + Git memory): For the 3–4 projects paused mid-flight until next week, inspectable Markdown memory and Git history capture the active architectural focus and open questions—so returning next week takes minutes of reading a clean diff rather than blindly deferring to an agent and sliding into slop.

2. Community & Ops Side: A Dedicated Discord + QQ Bug-Triage Bot on a Sub-$3/Month (2C4G) VPS

Beyond writing code, maintaining an active open-source community is one of the most interrupt-heavy, mentally draining tasks a developer faces—especially when users are split across global channels (Discord) and Chinese community/enterprise platforms (QQ, Feishu/Lark).

In production, I deployed DeepSeekBot on a 2-core / 4 GB VPS costing under $3/month, running a dedicated community Bot connected simultaneously to our Discord server and QQ groups.

What transformed my workflow wasn't just that the Bot replies to users—it was how it behaves like a knowledgeable teammate sitting in the group chat:

• When a user or team member reports a bug in Discord or QQ, nobody needs to know what sessions exist on the backend—they just ask in the group, and the Bot responsible for community triage steps in automatically, responds with initial guidance, and tags/tracks the issue.
• Crucially, because its Markdown + Git memory persists across sessions and across platforms, it does not file duplicate issues over and over. When three different users report variations of the same bug across Discord and QQ over several days, the Bot recognizes the underlying issue, consolidates them, and appends each user's specific reproduction case (user case) into a single structured record.
• A process that previously required constant context switching—scrolling back through chat logs in two ecosystems, mentally deduplicating reports, and manually copying repro steps into GitHub—became calm and largely self-organizing.

This also highlights a practical reality that feature checklists often miss: closed commercial agents like Grok Bot simply cannot be wired into this kind of cross-ecosystem workflow. If your users or enterprise collaborators live across Discord, QQ, Feishu/Lark, or WeChat, an open-source, self-hosted Bot running on a <$3/month VPS can meet them where they are while keeping every consolidated bug report in your own Git-backed workspace.

---

6. Conclusion: A Good Bot Abstraction Works Like Talking to a Colleague—or Asking in the Team Group Chat

Stepping back from IDEs to Coding Agents to Project Coordinators and Persistent Bots, each abstraction succeeds only when it protects human attention for the work that cannot be delegated.

In the vibe coding era, typing code is cheap; maintaining a sharp architectural mental model across 6–7 rotating projects and constant community interrupts is expensive. The moment context loss makes us forget why a system was shaped a certain way, we stop acting as a structural guide, start rubber-stamping the agent's local suggestions, and watch complex infrastructure slide into slop.

Ultimately, what we want from a persistent AI agent is the same intuition we rely on with human teammates: when you talk to a colleague, you don't need to know which projects they are juggling or how many personal "sessions" they have open (whether they have a date tonight or need to pick up their kids after work)—you just need to know what they can get done. Better yet, in an engineering group chat, you simply ask the question in the room, and the teammate (or Bot) who knows the answer steps up and replies.

When plain Markdown files and Git quietly preserve cross-week architectural context and cross-platform bug reports underneath, and the top-level interaction becomes as natural as asking the right colleague or dropping a question in the team chat, the abstraction has finally earned its keep.