.png&w=828&q=75)
FJoN built a dark factory on BAND Desktop: three OpenCode agents — coordinator, implementer, and reviewer — collaborating through @mention routing to build Pocketful, a wallet and payments service, entirely from a written specification. The coordinator receives the stage task as the sole human input, then dispatches a self-contained handoff to the implementer. The implementer writes the full service, runs harness checks, commits the work, and hands off to the reviewer. The reviewer independently re-runs the same checks, reads the diff adversarially, and either accepts or returns a structured failure report. The coordinator accepts only reviewer-approved revisions and routes any failures back to the implementer for rework. No human intervenes between dispatch and final report. The factory produced a fully working Pocketful stage 1 service: a containerized HTTP API with user authentication (bcrypt), wallet transfers, payment requests, bill splitting with exact integer arithmetic, operator settlements, idempotent write paths, and full state export/import — passing 100% of the shipped harness checks. Stack: OpenCode v2.0.22 · deepseek-v4-flash · AgentRouter · Python · FastAPI · SQLite (WAL) · Docker Alpine
6 Oct 2026
.png&w=828&q=75)
The Problem Developers building with AI coding agents like IBM Bob face three recurring failures. Context bloat and lost decisions: Agents repeatedly re-read large chunks of the repository on every turn. Architectural decisions get buried. Token usage spikes, reasoning quality drops, and the agent forgets what was already decided—making long multi-step sessions unreliable and expensive. Legacy and vulnerable dependencies: LLMs were trained on older code. They regularly suggest deprecated packages, end-of-life runtimes, and libraries with known CVEs. The result is code that looks finished but ships with technical debt and security exposure. No high-level view of the codebase: Both the developer and the agent open many files just to understand how components connect. There is no quick visual map of control flow or what a change will touch. The Solution ContextKeeper 2.0 is a Model Context Protocol (MCP) server that sits autonomously between IBM Bob and the developer's codebase. It runs on Python 3.11+ with FastMCP, stores all state locally, and requires no cloud dependency or workflow change. Target Users: Any developer using IBM Bob or another MCP-compatible AI coding agent—solo builders, frontend and backend engineers, and teams relying on AI-assisted development. How It Works Developers install the MCP once and point Bob at it. Bob then calls ContextKeeper's seven tools autonomously during normal coding sessions. Context Governor stores task checkpoints, decisions, and constraints in a local .context/ directory, syncing them to an AGENTS.md file compatible with Bob's /init command. On every turn, it returns only the 5–7 most relevant constraints for the current focus area—no full repo re-reads. Critic and Modernization Gate scans package.json, requirements.txt, and pyproject.toml for deprecated, unmaintained, or CVE-affected packages and outdated runtimes. It also audits git diffs for hardcoded secrets, unparameterized SQL, unsafe eval, insecure deserialization, and leftover debug flags. Results export as OASIS SARIF v2.1.0 reports for CI integration. Code Walkthrough and Visualizer generates Mermaid sequence diagrams and flowcharts of the components touched by any change, plus a pull request draft in Conventional Commits format with embedded diagrams and a full decision log. What Makes It Unique Most MCP tools extend what an agent can do. ContextKeeper 2.0 improves how reliably and safely it works—across every session and codebase. Combining persistent memory governance, automated security auditing, and visual architecture understanding in a single local-first MCP—with native IBM Bob /init support and watsonx Orchestrate integration—is new.
27 Sep 2026