Agent-Me: a runnable architecture for an inspectable AI Agent Twin
Distill your knowledge, memories, and decisions into an open-source, inspectable AI Agent Twin.
At a glance
- What is it?
- Agent-Me is a Python and React reference implementation that turns reviewable Markdown about you into a sequential multi-agent RAG pipeline. Its selling point is not recall but auditability: every stage produces typed artifacts and a public trace.
- Who is it for?
- Adopt Agent-Me if you want a small, readable codebase where personal memory is version-controlled Markdown and every stage of the answer pipeline emits a typed artifact you can inspect. Do not adopt it if you need automatic temporal reasoning over conflicting facts, a managed vector store, or production-grade multi-tenant isolation; the README states those are future work.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Agent-Me targets: recall without representation
The README draws a line between a chatbot that remembers facts about a person and a system that can represent that person. Its framing is blunt: most personal assistants are a prompt, a vector database and a chat interface. That combination can quote your biography or imitate your tone, but it has no notion of which beliefs are supported, how old they are, or how confident the system should be.
Agent-Me is aimed at people who find that unsatisfying. The README's stated audience is the owner of the data: someone who wants to feed in knowledge, memories, projects, preferences, experiences and decisions, and get back an inspectable twin. The public repository deliberately ships fictional examples, and the README says each owner keeps real identity and memory in a separate private workspace. That split is the clearest signal of intended use. This is not a hosted assistant you sign up for. It is a scaffold you run yourself, with your own corpus outside the repo.
Markdown as the memory substrate, and why that choice constrains everything
The current memory layer is version-controlled Markdown. The README calls it small, explicit and inspectable, and the architecture diagram labels the same store as reviewable personal knowledge. Retrieval runs against it through what the README describes as a bounded deterministic local retriever.
Deterministic is doing real work in that sentence. A deterministic retriever over plain files means the same query against the same commit yields the same evidence, which is what makes the versioned evaluation cases meaningful. It also means the system inherits the limits of file-based memory. There is no automatic temporal reasoning in the current implementation; the README says so directly and lists richer identity models as future work. If two Markdown entries contradict each other, nothing in the described pipeline resolves which one is current. An optional private workspace adds SQLite-backed profile entries, persisted chat transcripts and user-confirmed memories, but that is an addition to the Markdown substrate, not a replacement for it.
Planner, Researcher, Critic, Writer and the optional Verifier
The pipeline is sequential, not a swarm. The baseline policy runs Planner, Researcher, Critic, Writer. The verified policy adds Verifier as a fifth stage. Roles communicate through typed Python contracts, and the README names the artifacts: a Plan from the Planner, an EvidenceBundle from the Researcher, a Critique from the Critic, a citation-aware answer from the Writer.
The Researcher pulls exact source excerpts and metadata, and the diagram shows it calling the same deterministic search used by single-path Q&A. The Critic is described as an evidence-sufficiency gate rather than a style reviewer. That is the most interesting design decision in the project: the README claims the system can refuse synthesis when evidence is insufficient instead of filling gaps with confident invention. The Writer then produces the grounded response, and the optional Verifier checks citation paths and metadata before output passes. The README is explicit that the goal is not to maximize agent count but to make important decisions explicit and testable. Five roles is a small number by current fashion, and that looks deliberate.
What the public trace shows, and what it refuses to claim
Agent-Me exposes a public execution trace: role outcomes, safe intermediate summaries, evidence, metrics, retrieval activity and verification results. The README states plainly that the trace does not expose or claim to expose a model's private chain-of-thought. Given how often that phrase is used loosely, the disclaimer is worth noting. What you get is stage-level accounting, not hidden reasoning.
That distinction matters for anyone evaluating the project as an audit tool. A trace of typed artifacts and metrics answers questions like which sources were retrieved and whether the Critic blocked synthesis. It does not answer why a model phrased something a particular way. If your requirement is interpretability of the model itself, this trace will not satisfy it, and the README does not pretend otherwise.
Getting it running: FastAPI, React and the versioned evaluator
The stack is FastAPI on the backend and React on the frontend, with Python 3.11+ and Node.js 22+ per the badges in the README. The architecture diagram shows the browser sending a typed request to a FastAPI request guard, which routes to either single-path Q&A or the sequential role orchestrator. Optional provider mode connects to an OpenAI-compatible provider; the baseline path uses the local retriever.
The evaluation story is the part to exercise first. Versioned cases feed a deterministic evaluator, and the diagram shows that evaluator wired into GitHub Actions through ci.yml. The README says the cases cover supported, unsupported, adversarial and boundary requests. The README does not document rollback behaviour for memory changes, and it does not publish a migration guide for moving a private workspace between versions. Those are gaps to plan around rather than assume away.
Where the design breaks down
Three limitations are visible from the documentation alone. First, temporal reasoning: without it, a memory store that accumulates over years becomes a pile of equally weighted claims, and the evidence-sufficiency gate may treat a stale entry as valid support. Second, the retriever is described as bounded and local, so scaling to a large personal corpus is an open question the README does not answer. Third, the README lists knowledge graphs, richer structured memory, typed intent routing and broader tool calling as natural extensions, explicitly not finished capabilities.
There is also a category mismatch to watch. The project name and framing invite comparisons with personal assistants, but the shipped artifact is closer to a reference implementation. If you want a product that ingests your email and calendar tomorrow, Agent-Me is the wrong tool. The README's own emphasis on testable architecture over capability is the honest signal here.
How it differs from a plain RAG chatbot
The obvious alternative is a conventional RAG stack: chunk your notes, embed them, retrieve top-k, generate. That approach optimizes for answer fluency and gets out of the way. Agent-Me inserts a Critic between retrieval and writing, and optionally a Verifier after writing, which changes the failure mode from a confident wrong answer to a refusal. Whether that trade is worth it depends on your use case. For a twin that speaks on your behalf, refusal is usually the better default.
The second difference is provenance. A standard vector pipeline can return source chunks, but Agent-Me's typed EvidenceBundle and citation-path checks make the linkage a first-class artifact that the Writer must respect and the Verifier can reject. The cost is latency and moving parts: five sequential stages against one generation call. The README's evaluation fixtures exist precisely to make that cost measurable rather than assumed.
Licence, maintenance and upgrade cost
Agent-Me is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are included. The README does not discuss trademark or attribution requirements beyond that, and nothing here is legal advice; if you plan to ship a derived product, read LICENSE yourself.
Maintenance looks current. The repository is not archived, and the last push was on 2026-09-13. Releases moved from v1.0.1 and v1.1.0 in late August 2026 to v2.0.0 on 2026-08-29, described as an auditable multi-agent RAG reference implementation, so the project is still changing shape rather than frozen. That pace cuts both ways: the typed contracts between roles are the interface most likely to shift, and the README does not document a deprecation policy or a compatibility guarantee across minor versions. Pinning a release tag and re-running the versioned evaluation cases after each upgrade is the practical way to absorb that cost.
Editorial conclusion
Adopt Agent-Me if you want a small, readable codebase where personal memory is version-controlled Markdown and every stage of the answer pipeline emits a typed artifact you can inspect. Do not adopt it if you need automatic temporal reasoning over conflicting facts, a managed vector store, or production-grade multi-tenant isolation; the README states those are future work. Before committing, read docs/ARCHITECTURE.md and run the versioned evaluation fixtures to see what the evidence-sufficiency gate actually rejects on your own documents.
Community notes