GitHub Hidden Gem Pick #2 — Reading the Code of eidan, a Personal Agent OS with One Star

Conclusion first: the skeleton is solid, the type gate is broken

eidan (sielay/eidan) is a self-hosted personal agent OS that opens with the blunt sentence "own your cognitive infrastructure." It speaks three open protocols simultaneously — MCP (tools), AG-UI (chat), and A2A (agent-to-agent communication) — and stores all memory in your own Postgres. Judged by concept alone, it is more ambitious than #1 gno.

Here is what we found after cloning and measuring it directly. The license documentation is exemplary, and there is a real typing discipline. But run tsc --noEmit across the whole monorepo and you get 180 errors across 11 packages. That is the exact opposite of #1 gno, which was "tsc clean." Not every neglected gem shines the same. This record notes what gleamed and what is cracked.

Measurement environment

Operator-environment measurement baseline. The inability to run the full tests is stated as a limitation. Only what was measured, not what was felt.

Structure: the plugin is the product

eidan's design is simple. The core is a thin agent engine, matbot (vendored as a separate repository via a git submodule, Apache-2.0), and on top of it sit about fifty plugin packages covering mail, calendar, CRM, finance, code, and more. Plugins attach to the core only through a string-keyed service registry; they never modify the core directly. At deploy time, the bundles of plugins you selected are vendored into the host image. The structure itself matches the concept of "an agent that carries only the abilities you chose."

The entry points split three ways. The AG-UI chat runs on 8090, the MCP server on 8091, the A2A agent on 8095, and the reference web UI on 3001. All four ports were confirmed directly in the code and match the README claims. Points where speech and code do not diverge are material you can trust.

Measurement 1: 11 packages fail type checking, 180 errors

This is the finding that hurt most. We forced the whole monorepo to run with pnpm -r run typecheck --no-bail. The default pnpm -r stops at the first failure (bail), so --no-bail is mandatory.

• 11 failing packages: boards, charles-decks, charles-domains, crm, finance-google-trends, finance-trading212, frontend-agui, memory, storage-postgres, tool-failure-handler, ventures
• Of the 180 errors, 132 are in production code (src) and 48 are in test files

A representative case is TS2375 in packages/memory/src/tools.ts. It is the pattern of assigning undefined directly to an optional field while exactOptionalPropertyTypes is on. The configuration was made strict and the code failed to follow it. The rest are variations on the same theme. The fact that 48 errors sit in neglected test files is also evidence that there is no CI gate.

That said, context deserves a fair record. All 56 packages set strict: true, and excluding tests there are 40 occurrences of any across 656 files. This looks more like the trace of a project that chose speed than one that gave up on typing. Even so, failing type checking under the version number v0.20.0 is a defect the user must verify before real use.

Measurement 2: tests do run, you just need a database

The full test suite requires Postgres, so it could not run in an isolated environment. Instead we did a trial run of the one package that needs no database, tool-failure-handler.

• Result: all 6 tests passed (124ms)
• The runner is node's built-in node:test plus the matbot registry loader. There is no separate test framework dependency.

This means the test infrastructure itself is sound. The problem is coverage conditions, not correctness. Since most tests cannot run without a database, verifying on the receiving end forces a one-line Docker Compose. The fact that the barrier to entry sits in the environment rather than the code is worth recording.

Measurement 3: no hardcoded secrets, license documentation is exemplary

• No hardcoded API keys or tokens. Only .env examples and placeholders exist
• Core and all 37 packages are AGPL-3.0-or-later. The matbot submodule is Apache-2.0, separated and stated in the LICENSE
• LICENSE.md goes as far as trademarks and a CLA (contributor license agreement). At a one-star personal project, that level is rare

What is missing, what is overstated

The README's "one-line launch on a Raspberry Pi" is based on Docker Compose, so it is not a false claim. But in small print up front it notes that without an API key (Anthropic, etc.) the engine will not run. In other words, it is not fully offline. A local LLM (Ollama) path exists in the code, but the default is a cloud API. The scope of "ownership" is the data store, not the model.

Verdict: a cracked gem, but it is a genuine stone

If gno was "a stone that shines with no polishing," eidan is "a rough stone with a real form." The design (plugin OS plus three protocols plus your own database) is close to the correct answer for the 2026 personal agent wave, and the license and documentation discipline is real. But 180 type-check failures are cracks the recipient has to fill by hand.

We recommend trying it. Run git clone --recurse-submodules, then pnpm -r --no-bail run typecheck first, look at where the cracks are, and only then decide. If you can afford that repair, this is a skeleton you will rarely find at one star.