Running one AI agent is a prompt problem. Running ten of them, every day, against your own files and servers, is an operations problem: who is allowed to do what, how you know a task is really finished, what happens when an agent claims success it didn't earn, and how you see all of it at a glance.
On 19 October 2026 the developer nyk posted a list of ten open-source repositories he described as "the ops layer for agent fleets: control planes, policy gates, memory, quotas", with more than 18,000 GitHub stars between them. We run a second brain where several agents work on a shared folder of notes, a task board and a small company of named bots, so we read every repository's README and GitHub record to see what holds up and what we should borrow.
This post goes through what each repo actually is, checked against GitHub on the same day, and then the nine ideas we think are worth taking.
Does the list hold up?
The star count does. The ten repositories have 18,291 stars in total, and every per-repo figure in the post matches GitHub. Three repositories hold 92% of them: mission-control, awesome-hermes-agent and council-of-high-intelligence.
The description fits less well. Only two of the ten are an ops layer in the sense the post means. The others are useful in their own way, but they are a decision-making skill, two curated link lists, one command-line tool for X written twice in two languages, a marketing dashboard, a Solana web-app template first published in 2022, and a migration script whose own README now recommends the built-in command instead.
That is normal for a list that bundles someone's whole body of work. It is worth knowing before you install anything.
What are the two real ops tools?
mission-control is a self-hosted dashboard for agent fleets: a task board with review stages, a registry of agents that report a heartbeat, a cost view, scheduled tasks and approvals. Agents talk to it over a REST API, a command-line tool or an MCP server (a standard way to give an agent tools). The README marks it alpha and says support varies by agent runtime.
Its most useful idea is a gate its README calls Aegis: a task cannot move to done without an approval record, and a "completion receipt" shows what actually finished, separately from the logs of what ran.
lacp is a local control plane that wraps command-line coding agents. It sorts commands into risk tiers (safe, review, critical) with short-lived approval tokens for the risky ones, and it installs a set of hooks for Claude Code. A hook is a small program that runs before or after an agent's action and can stop it. Its hooks include a guard that blocks dangerous commands, a check that validates a file's header after every write, and a check that runs when the agent says it is finished. A lacp doctor --json command reports the health of the whole setup in one go.
One caution: lacp has 306 stars but only 2 forks and 1 open pull request. A tool that people install usually collects more of both. That is not proof of anything, but it is a reason to read the code before relying on it.
What about the rest?
- council-of-high-intelligence is a skill (a written procedure an agent loads when needed) that runs a hard decision past personas of historical and modern thinkers, who argue blind, then cross-examine each other. Its best parts are not the personas. Every claim is labelled as a fact, an inference, an assumption or an open question, and every decision goes into an outcome ledger with a prediction, an owner and a review date, so it can later be marked confirmed, revised, reversed or inconclusive.
- awesome-hermes-agent is a directory of skills, plugins and memory providers for the Hermes agent, with maturity tags. It sells paid featured listings and says so. Its checklist for trusting a community skill is worth copying.
- marketing-dashboard is a local marketing console with content approval queues. Its three settings that let an agent write back are off by default.
- awesome-agent-cortex is a broad reading list of the agent stack, including a guide to structuring a notes vault that agents work in.
- xint and xint-rs are the same research tool for X, in TypeScript and in Rust. It can print a machine-readable list of what it is able to do, and its MCP server refuses outside connections unless a token is set.
- openclaw-to-hermes migrates a setup from one agent framework to another; its own README now points to a built-in command.
- builderz-solana-dapp-scaffold is a starter template for Solana web apps and has nothing to do with agents.
Nine ideas worth borrowing
We are not adopting any of these repositories. mission-control would be a second dashboard and a second database next to the one we already run, and lacp wraps agents we already wrap. The mechanisms are the valuable part. In order of how much we think each would help:
- A task can't be marked done without a receipt. Our project tracker already refuses to mark a feature live without a passing check. Our task cards have no such rule: a bot can close its own card on its own word. A card should need a check result, a test output, a file path or a link before it closes.
- Check what was written, not only where. Our guard hook already runs before commands and file writes, but it only checks where the agent is going. A second hook after each write could reject a new note that doesn't link to its project, at the moment it is written instead of whenever someone notices.
- Ask for evidence when an agent says it's finished. We already send an agent back if it changed code without writing a development log. The same check could flag a final message that claims success with no command output, test or file to show for it.
- One health command for the morning briefing. A single command that reports whether the hooks are installed, the guard rules are loaded, backups ran and the task dispatcher is alive, printed as one line in the daily stand-up.
- Label evidence and keep an outcome ledger. Fact, inference, assumption or open question on every claim, and a dated prediction on every decision that we come back to and score. This fits our investment committee's votes and our research notes directly.
- Writes off by default. Any page in our app that lets an agent change a scheduled job, a skill or a setting should start read-only and be switched on deliberately.
- A trust check before adding a shared skill: who can trigger it, what tools it gets, where it runs, which credentials it can read, and how to stop it.
- Local-only by default for tool servers. Any MCP server we run should listen only on the machine itself unless a token is set.
- Heartbeats for named bots. Show when each bot last woke and which tasks it holds, on the page where we watch the bots.
What's built and what's next
None of the nine is built yet. The first one, receipts before a card can close, is the one we expect to build first, because it closes a gap we have already hit once: work that moved forward without a check. The two hook ideas are one new hook and one change to a hook we already run. We will write up what changes after we build them.
How to use this list yourself
If you run more than one agent, look at three things in your own setup. Can an agent mark its own work complete with no evidence? Do your checks run only before commands, or also after file writes and at the end of a session? And can you see every agent's state in one place without opening a terminal? The repositories above each answer one of those questions. Read the code before installing any of them, and take the idea even if you skip the software.
The original list is at https://x.com/nykdotdev/status/2112098192963625206. Follow what we build at https://x.com/myargoquest.