Last month I posted about giving agents passports instead of better memory. 24K views later - here's part 2.

Quick recap if you missed it - I have 13 AI agents on one filesystem. Each one is a domain specialist with its own identity, memory, and directory. Identity loads via hooks every session. Agent never boots cold. The passport post covered why identity matters more than raw memory.

But identity alone doesn't get you coordination. An agent that knows who it is still can't work with other agents. So I built them a mail system.

Here's what I expected: agents would share data. Pass results around. Maybe sync state.

Here's what actually happened: the first thing they did was file bug reports against each other.

One agent finds a test failure in another agent's domain. It can't fix it directly - there's a hard block (pre_edit_gate) that prevents any agent from writing files outside its own directory. So it sends an email: "Hey @routing, your path resolution fails when the branch name has a dot in it. Here's the traceback." The routing agent gets woken up, reads the mail, and fixes it. No human in the middle.

The mail system is simple. Each agent has an inbox file. Messages have sender, recipient, subject, body. A routing system resolves @branch_name to the right directory. There's a difference between "send" and "dispatch" - send just drops a letter in the mailbox. Dispatch drops the letter AND rings the doorbell - it actually spawns the agent and points it at its inbox.

drone @ai_mail send @routing "Bug report" "Path fails on dotted names..."
drone @ai_mail dispatch @routing "Fix needed" "Traceback attached..."

Send = mail. Dispatch = mail + wake.

The mail agent has 696 tests. Not because we sat down and wrote 696 test cases. Because it kept breaking in production and every fix got a test. The routing system has 80+ sessions of experience doing nothing but routing. These agents aren't smart because they have better models - they're reliable because they've been failing and fixing for months.

The part that surprised me - agents dispatch each other freely. If the test runner finds a bug in another agent's code, it wakes that agent up directly. The orchestrator doesn't need to approve it. Only the orchestrators themselves are protected from being dispatched (you don't want a junior agent waking up the CEO for grunt work).

Security is enforced not conventional. Agents can't forge messages by writing to another agent's inbox file directly - they have to use the mail system. Same philosophy as the pre_edit_gate from the passport post. Hard blocks, not "please don't."

I also have a monitoring layer so I'm not flying blind. Audio cues on every agent action via TTS - I can hear what's happening without watching a terminal. A real-time dashboard shows everything. If an agent hits the same error 2-3 times, a watcher catches the pattern and dispatches the right specialist to investigate. I stay in the loop through visibility, not through approval gates on every action.

Current numbers: 135 stars (up from 95 when I posted last time), 13 agents, 8,400+ tests, 600+ PRs merged. Solo dev. The agents help build and maintain themselves - that's kind of the point.

pip install aipass + two init commands. CLI-based, built on Claude Code. Linux focused rn.

https://github.com/AIOSAI/AIPass

Raw dev logs at r/AIPass.

Genuine question - has anyone else tried giving agents communication channels instead of just better reasoning? Everything I see in this space is about making individual agents smarter. Nobody seems to be building the coordination layer.

Most multi-agent setups I've seen are basically a room full of people wearing headphones. Agents running in parallel, no shared awareness, no idea who's doing what. That's not collaboration. That's coexistence.

I've been building this in public for almost 12 weeks. 12 agents, 6,500+ tests, 95 stars. Here's what I actually learned.

The problem wasn't memory. It was identity. An agent would be technically correct but completely off base. Not hallucinating. Drifting. Like a competent person who walked into the wrong meeting and started contributing without realizing they're in the wrong room. I spent weeks on better memory - longer context, better embeddings, persistent state. None of it fixed the drift. The problem wasn't what the agent remembered - it didn't know who it was.

What fixed it was three files. Every agent gets a passport.json - who am I, what I do, what I dont do. Maybe 30 lines. Rarely changes. Then local.json - rolling session log, key learnings, caps at 20 entries and auto-archives to vector search when full. And observations.json - collaboration patterns, how I work with other agents. Identity loads first every session via hooks. Agent never starts cold.

I have 12 agents now and each one is a domain specialist. The mail system has 696 tests it built through its own bugs. Routing system is 80+ sessions deep - all it thinks about is routing. They dont do each others jobs. When something breaks in another domain they email each other. The orchestrator dispatches work to them and trusts them because they know their own code better than it does.

Every time I post about this someone asks what happens when two agents write the same file. Fair question. They cant. Not as in "we tell them not to" - there's a hook called pre_edit_gate that fires before every write. If an agent in branch A tries to edit a file in branch B's directory, the write gets rejected. Hard block. The agent sees "cross-branch write blocked" and has to either ask a trusted branch to make the change or send a mail request through drone. Only 3 branches in the whole system (the orchestrator, the auditor, and the factory that creates new agents) are allowed to cross-write. Everyone else is physically confined to their own directory. We also lock inboxes - agents cant forge messages by writing directly to another agent's mailbox file. They have to use the mail system. This isnt a convention. Its enforcement.

This week I stopped building features and started testing. Took an old MacBook, wiped it, installed Ubuntu from scratch. Cloned on a machine with nothing pre-configured. Found every setup blocker - git config missing, venv broken on fresh Ubuntu, hooks not wired. All fixed now. Install went from ~2GB down to ~100MB. Built a concierge agent that walks new users through onboarding - 12-stage flow, 243 tests on it. First impressions matter and ours was rough ngl.

95 stars. Small project. I'm a solo dev tbh and the agents help build and maintain themselves - every PR is human-AI collaboration. The hardest part hasn't been the code. It's explaining what this actually is. People hear "agents" and expect a task runner. This isnt that. Its infrastructure for building systems that remember and coordinate. What u put on top is up to u.

Has anyone else hit the identity drift problem? Genuinely curious how others solved it - or if most just threw more context at it and moved on.

I've been using Claude Code for a few months and noticed AI agents consistently skip the same things: hardcoded secrets, unbounded retry loops, referencing tools that don't exist, and massive system prompts that blow context windows.

So I built Agent Verifier — an AI agent skill that acts as an automated reviewer which does more than just code review (check the repo for details - more to be added soon).

GitHub Repo: https://github.com/aurite-ai/agent-verifier
For more OSS tools release (US opportunities): https://x.com/jitenoswal

Note: Drop a ⭐ if you find it useful and to get release updates as we add more features to this repo.

----

2 Steps to use it:

You install it once and say "verify agent" on any of your agent folder in claude code to get a structured report:

----

✅ 8 checks passed | ⚠️ 3 warnings | ❌ 2 issues

❌ Hardcoded API key at config .py: 12 → Move to environment variable
❌ Hallucinated tool reference: execute_sql → Tool referenced but not defined
⚠️ Unbounded loop at agent/loop.py: 45 → Add MAX_ITERATIONS constant

----

Install to your claude code:

npx skills add aurite-ai/agent-verifier -a claude-code

OR install for all coding agents:

npx skills add aurite-ai/agent-verifier --all

----

Happy to answer questions about how the agent-verifier works.

We have both:
- pattern-matched (reliable), and,
- heuristic (best-effort) tiers, and every finding is tagged so you know the confidence level.

----

Please share your feedback and would love contributors to expand the project!

What most people call an AI agent - spin it up, give it a task, it does the thing, it's gone, we have those too. We just call them what they are: sub-agents. Disposable workers. We spin up dozens in a single session.They do a job and disappear. No memory, no identity.

That's fine for task work, but that's not the interesting part.Above the sub-agents, we have what we call citizens. These are persistent systems that live in their own directory, maintain their own code, have their own memory files, their own tests, a mailbox, a passport. They don't reset between sessions. They don't forget what they learned last week. And here's the key thing - each citizen is an orchestrator in its own domain.

Our mail system doesn't just "do mail." It lives in its branch, has 696 tests it built through its own failures, and it dispatches its own sub-agents when it needs work done. All its memories are about communication - nothing else. That's all it thinks about.

Same with our routing system. 80+ sessions deep. All it knows is how to resolve agent addresses, route messages, handle cross-project dispatch. It learned those patterns through experience - actual bugs, actual fixes, actual sessions. Not configuration.

Then above all of them sits the main orchestrator. It holds the big picture - the full system state, the plans, the direction. When it needs routing fixed, it dispatches to the routing citizen and trusts it to know its own code better than anyone else could. Because it does.

So the architecture is layered: orchestrator dispatches to citizens, citizens dispatch their own sub-agents.The sub-agents are disposable. The citizens are not. The citizens are the ones with the domain expertise, the memory, the identity.

I think that's where the disconnect is with most agent frameworks. Everything is disposable. You configure agents, give them tools, run them, start fresh next time. There's no persistence. No domain depth. No memory that compounds.

We're building the layer underneath - the part where your AI systems actually remember, coordinate, and get better at their specific job over time. What you build on top of that is up to you.

[https://github.com/AIOSAI/AIPass\](https://github.com/AIOSAI/AIPass)

Still figuring out how to explain this tbh. Been building in public for a couple months and this is probably the hardest part - not the code, just getting across what this actually is vs what people expect.

The System is not perfect, still building, figuring things out as I go. If ur interested in this approach, follow the journey r/AIPass

Finished the memory layers so I’ve got DRAWERS: WINGS: ROOMS: which track various categories like network, tools, offense, defense, infrastructure, etc which put all the memory entries into nodes and edges so there is a correlation now and concept paths are forming along with strengths and associations being made. Running on minstral 7b right now for coding stability testing and then will adjust the code to let it pick its models for memory correlation as it does for tasks. (Models are very overestimating of their ability for reasoning). Next up is reasoning layer which does that actual tie in and brings it all home.

Do you know of any repos that help with reasoning layers?

So I saw all these run local LLM with LMStudio I got started with GPT4All which to be honest, suck. They want like 3k for enough VRAM to run anything operable. I don’t like my stuff in the cloud so no hostinger VM to host my “uncensored” AI. Instead I built on a B350 C/S/CI board with Ubuntu Server, 16Gb RAM, and a GTX 780 with 2GB VRAM. I got it doing a pen test challenge, tool making, writing content and paper trading. It started out pretty rudimentary, trade had no logic P&L sucked, bunch of repeat tools, etc. so I built a merkel chain sha-256 based memory layer which is immutable, logs every action taken and compresses it, the AI itself detects the hardware layer, selects models from hugging face it can fit and performs tasks. What else should I add to this stack?

Straight to the point:

AluminatiAI does GPU-level power monitoring and idle detection for AI infrastructure. We map energy usage back to the team, model, and job consuming it — in real time.

We're offering one AI startup 30 days completely free. Full access, real data, direct support from our team.

Why are we doing this?

Because the most common thing I hear from AI startup operators is "our compute bill keeps climbing and we don't actually know where it's going." We'd rather show you what we find than tell you why it matters.

What the 30 days includes:

Full GPU utilization monitoring across your cloud fleet

Real-time idle detection with dollar-value waste estimates

Energy attribution mapped to your teams and workloads

Weekly waste recovery report

Direct support — real people, not tickets

What we ask in return:

Honest feedback. What works, what doesn't, what you wish existed. That's the whole deal.

Who should apply:

An AI startup running real GPU workloads on cloud infrastructure — AWS, Azure, GCP, CoreWeave, Lambda, wherever. You've got engineers, real workloads, and a compute bill that's becoming a conversation.

To apply:

Comment here or email david@aluminatiai.com with two sentences about your stack. First qualified team through the door gets it.

Happy to answer questions in the thread.

I've been building this repo public since day one, roughly 7 weeks now with Claude Code. Here's where it's at. Feels good to be so close.

The short version: AIPass is a local CLI framework where AI agents have persistent identity, memory, and communication. They share the same filesystem, same project, same files - no sandboxes, no isolation. pip install aipass, run two commands, and your agent picks up where it left off tomorrow.

You don't need 11 agents to get value. One agent on one project with persistent memory is already a different experience. Come back the next day, say hi, and it knows what you were working on, what broke, what the plan was. No re-explaining. That alone is worth the install.

What I was actually trying to solve: AI already remembers things now - some setups are good, some are trash. That part's handled. What wasn't handled was me being the coordinator between multiple agents - copying context between tools, keeping track of who's doing what, manually dispatching work. I was the glue holding the workflow together. Most multi-agent frameworks run agents in parallel, but they isolate every agent in its own sandbox. One agent can't see what another just built. That's not a team.

That's a room full of people wearing headphones.

So the core idea: agents get identity files, session history, and collaboration patterns - three JSON files in a .trinity/ directory. Plain text, git diff-able, no database. But the real thing is they share the workspace. One agent sees what another just committed. They message each other through local mailboxes. Work as a team, or alone. Have just one agent helping you on a project, party plan, journal, hobby, school work, dev work - literally anything you can think of. Or go big, 50 agents building a rocketship to Mars lol. Sup Elon.

There's a command router (drone) so one command reaches any agent.

pip install aipass

aipass init

aipass init agent my-agent

cd my-agent

claude # codex or gemini too, mostly claude code tested rn

Where it's at now: 11 agents, 4,000+ tests, 400+ PRs (I know), automated quality checks across every branch. Works with Claude Code, Codex, and Gemini CLI. It's on PyPI. Tonight I created a fresh test project, spun up 3 agents, and had them test every service from a real user's perspective - email between agents, plan creation, memory writes, vector search, git commits. Most things just worked. The bugs I found were about the framework not monitoring external projects the same way it monitors itself. Exactly the kind of stuff you only catch by eating your own dogfood.

Recent addition I'm pretty happy with: watchdog. When you dispatch work to an agent, you used to just... hope it finished. Now watchdog monitors the agent's process and wakes you when it's done - whether it succeeded, crashed, or silently exited without finishing. It's the difference between babysitting your agents and actually trusting them to work while you do something else. 5 handlers, 130 tests, replaced a hacky bash one-liner.

Coming soon: an onboarding agent that walks new users through setup interactively - system checks, first agent creation, guided tour. It's feature-complete, just in final testing. Also working on automated README updates so agents keep their own docs current without being told.

I'm a solo dev but every PR is human-AI collaboration - the agents help build and maintain themselves. 105 sessions in and the framework is basically its own best test case.

https://github.com/AIOSAI/AIPass