← Carlos Cardona

AMIKO. Your second brain.

May 2026 - present · amikobrain.com · Personal project

---

Amiko is a personal workspace where a UI and an agent operate over the same context. The surface is the tools of daily life: activities planning, goals, finances, contacts, links, ideas. The brain is an agent that reads and writes the same files I do.

---

I added "Run a marathon" to tomorrow's plan. Unprompted, Amiko flagged it: tomorrow was also the deadline on an important goal, with the big items still open. It laid out the conflict and offered three ways to resolve it: drop it, push it, or reshape it into a short run.

---

INSIGHT

The cost of building software has shrunk to the point where building my own Trello, calendar, and CRM, shaped exactly to my use case, became viable. Owning them together buys what no SaaS stack can: all my context in one store, under my control, shared on my terms. The agent on top is better precisely because nothing is siloed. It sees everything at once.

WHAT I BUILT

  • Proactive AI agent
  • Weekly planning and calendar
  • Kanban board
  • Cashflow and invoice capture
  • Contact enrichment
  • Link enrichment
  • Chat with memory
  • Dashboard, dark and light

HOW IT'S BUILT

Vue 3 front, Node and Express back, Firebase auth. Each account's context is markdown with YAML frontmatter in a private GitHub repo, provisioned programmatically at signup from a template. The agent is Claude Code spawned as a subprocess, working directory scoped to that context folder, streaming its tool calls live to the UI. Each task runs under its own tool allowlist. Git history doubles as the audit trail.

DECISIONS

Markdown for knowledge, a database for volume. The agent reads the knowledge base with the same tools I do, every change is a git diff, and the data is portable: clone your repo and leave. But files are wrong for high-volume, machine-written data, so the comms timeline lives in MongoDB Atlas with a vector index. The cost is two substrates to keep coherent. The rule: if losing it would hurt and I want to own it, it is a file; if machines write it at volume, it is a row.

Least privilege per agent task. Every agent job runs with its own tool allowlist. Chat reads and writes files but gets no shell. The email drafter is read-only. Contact research adds web search and fetch. One spawn pattern, different capability sets per task: the agent that writes in my voice cannot browse, and the agent that browses cannot draft. One broadly-permissioned agent would be simpler to wire, but hands every task the full blast radius. I chose containment over convenience.

Assistant state lives outside the knowledge base. Flags, sessions, and the agent's bookkeeping sit in a separate directory on the server, never inside the repo. Clone it and you get your knowledge, not my machinery. It also keeps the git history clean, so the backup log reads as the story of your context, not the assistant's internals. The cost is two state locations to coordinate; the payoff is a clean ownership boundary.

One private repo per account. Provisioned programmatically from a template at signup. Isolation comes free from the structure: there is no shared store to leak, and no query can return someone else's data because there is no place where two accounts' data coexist. I turned down a shared multi-tenant database with row-level access control. It also makes the ownership promise literal rather than a policy claim: your context is your repo, and you can take it with you.

OUTCOMES

  • Planning, notes, finances, and chat in one place, used daily from my phone
  • Every person I meet and link I save gets enriched automatically, with no effort from me
  • The whole context is version-controlled and portable as a git repo: no third party holds my data

LEARNINGS

  • Building for your own problem compresses iteration brutally. I feel the pain daily, so I can evaluate in minutes whether something is solved. No user interviews, no proxy metrics: the feedback loop is me, tonight.
  • Databases exist for a reason. I went in wanting to see how far plain files could go, and the answer is: far, but not everywhere. The real learning is not "use a DB", it is the sharper question I now carry into every project: what properties (queries, volume, indexes, concurrency) actually force one, and what is just habit.
  • Spawning an agent over raw files is the most flexible retrieval there is, and sometimes the slowest. The real tradeoff is latency against quality: when the agent reads the whole context, its answers are more accurate and more capable, and slower for it. Structured retrieval buys the latency back but lowers that ceiling. Watching it grep everything to answer a simple question showed me exactly where each is worth it.

STATUS

Two weeks of free time to a working v1, in May 2026. Since then I use it daily and update it passively, as using it shows me what to change.

Next, when usage demands it: a retrieval layer for when context outgrows file reads, an MCP server so external agents can work over the context, and a permission layer for lending scoped slices to people and agents I trust.