memex: training for the Forward Deployed Engineer era with a private memory brain on AWS

Or: what happens when an engineer gets tired of explaining himself to his own tools.

Before AI, and after

First, the way this job used to look.

A few years ago, if a company wanted a custom internal tool, the path was long: workshops, a requirements document, a team, a budget, a quarter. I sat somewhere in the middle of that as a cloud engineer - building the infrastructure, watching good ideas die in handover documents. Knowledge lived in people's heads and in wikis nobody read. When someone left, their know-how left with them.

Then AI tooling got serious, and the math changed. One person who understands both the business problem and the cloud can now sit down with a company, find the process that quietly eats two months a year, and ship a working tool for it in days. Not a slide deck - a running application.

There's a name floating around for this way of working: Forward Deployed Engineer. Someone who embeds with a company, learns how the place actually works - not how the org chart says it works - and deploys AI where it hurts. Let me be precise, because colleagues read this blog too: that is not my job title, and it's not a description of my day job. It's a hat I've been trying on for about half a year in my own time - side projects, weekend builds for friends' businesses, endless experiments - because I think it's where this profession is heading, and I'd rather learn the way of working before it becomes the job description.

The most fun engineering I've done. Also a memory shredder.

One month my evenings are full of warehouse logistics for a friend's company. The next it's a time-tracking tool. Then a Kubernetes upgrade study. Whatever belongs to an employer or to someone else's business stays there - that's the deal, and I don't bend it. But everything around the work is mine to keep: the architecture patterns that held up, the AWS traps I walked into, my side projects, my notes, the half-finished idea I mumbled into a voice memo at 11pm.

And here's the embarrassing part. I help companies stop losing knowledge, while my own knowledge lived in twelve places at once. An Obsidian vault. Git history. Old chat sessions. Voice memos. My head, allegedly. Every new AI session started from zero, and there I was again - re-explaining my own infrastructure to a tool that had helped me build that same infrastructure the day before.

At some point that stopped being funny. So I built memex.

What memex is, in plain words

memex is a private memory service. It runs in my own AWS account, it holds whatever I decide to feed it - notes, project docs, source code, and in my own install even my mail and calendar (that part is my personal wiring, not something the public repo ships) - and any AI tool I use can ask it questions.

If you don't write code, here's the version I'd tell over coffee: imagine a new colleague who has read every note you ever wrote, never forgets any of it, never leaves the company, and answers any question in two seconds - always quoting where they read it. That colleague costs less than your coffee budget. That's memex.

The technical version: the asking happens over MCP. MCP (Model Context Protocol) is an open standard that lets AI tools call external services - databases, APIs, memory stores - through one common interface. So whether I'm in Claude Code, Cursor, or Codex that day, or asking from my phone on a train, everything talks to the same brain.

The name is stolen, and I stole it with pride. In 1945, Vannevar Bush described a hypothetical desk-sized device he called the memex - a machine where a person would keep all their books, records, and letters, "an enlarged intimate supplement to his memory." Eighty years and one weirdly good embeddings API later, you can actually have one.

One thing memex refuses to be: a chatbot. It never writes answers. When my coding agent asks it something, memex hands back ranked excerpts from my own notes, each with a pointer to where it came from, and the agent on my laptop writes the answer from those. That split is deliberate. The brain remembers; the agent thinks. It also means every answer comes with receipts - I can always click through to the note it was quoted from.

Here's a real moment. Fresh session, me typing:

"When did I move memex off PGLite, and why?"

Claude Code quietly calls memex (simplified):

{
  "method": "tools/call",
  "params": {
    "name": "search",
    "arguments": { "q": "PGLite migration why moved", "k": 5 }
  }
}

And gets back excerpts like this:

{
  "hits": [
    {
      "sourcePath": "/vault/20-projects/memex/session-notes.md",
      "content": "PGLite on EFS lost data on SIGKILL - the move
                  to RDS fixed that class of failure...",
      "score": 29
    }
  ]
}

Two seconds, and I have the decision, the date, and the reason - quoted from a retro note written months ago by a version of me who was sure he'd remember. He never remembers.

The moment it clicked

The payoff isn't any single lookup. It's that sessions stopped starting from zero. My kickoff prompt these days boils down to: "You know where everything is - ask the brain." The agent pulls my infrastructure layout, my past decisions, my conventions, and just gets on with it.

Before memex, a session opened like this: "So, I have this EC2 instance, it runs Docker, the tunnel token is in Secrets Manager... no wait, let me check which account that was."

After memex: "Add a health check to the morning briefing timer." That's it. It already knows what the morning briefing is, which timer fires it, and that the chat ID deliberately lives outside the repo.

Fifteen minutes of throat-clearing per session, gone. Multiply by every session, every day.

What's actually inside

Under the hood memex is a Bun + TypeScript service sitting in front of Postgres with the pgvector extension. Everything I'm about to describe lives in the open repo at github.com/timurgaleev/memex - clone it and you get the whole thing: the memory service, the Terraform that builds the AWS setup, the security gates, the docs. The pipeline is boring on purpose:

1. Ingest. I decide what gets indexed - a folder, a repo, another source. New sources never add themselves; the ones I've configured get re-swept on a schedule, and re-indexing the same path replaces the old version. The brain's database is the store it searches; anything indexed from my vault or a repo can be re-ingested from there, and the database itself gets backed up like any Postgres.
2. Chunking. Documents get split into pieces that respect structure - markdown by sections, source code by functions and classes. A sanity gate scores incoming text and quarantines scraper junk before it wastes an embedding.
3. Embeddings. Each chunk becomes a 1024-dimensional vector via Amazon Titan v2. If "embedding" is a new word: it's the meaning of a piece of text written down as a long row of numbers, so that texts about the same thing end up with similar numbers. That's the trick that lets "why did storage keep dying" find a note that never contains the word "dying". Every vector carries a signature (model + dimensions), so if I ever switch embedding models, memex can spot every stale vector - and, with a flag turned on, re-embed them automatically.
4. Hybrid search. Every query runs keyword search and vector similarity at the same time, then fuses the rankings. Keyword catches exact identifiers - "t4g.medium", "SIGKILL". Vectors catch meaning - "why did storage keep dying". I tried living with each one alone; each alone misses half of what I actually ask.

That's the base. Above it lives the part I actually show off to people - structured memory. Most of it is opt-in and uses paid model calls, so it's off by default in the repo:

• Entity facts. memex pulls subject-predicate-object facts out of notes ("memex → runs-on → EC2 t4g.medium") with confidence scores. Facts can supersede each other, decay over time, and keep an audit trail of why something was forgotten. Ask "what do I know about project X" and you get a compiled summary instead of raw search hits - still model-extracted, which is exactly why every fact drags its confidence score along.
• A knowledge graph. Notes, projects, and people are linked with typed edges. "Show me everything connected to the n8n server" is a single graph walk.
• A code call graph. When memex indexes a repo, it parses who-calls-what. My agent can ask "what breaks if I change this function" and get an actual blast-radius answer. Do you need all of that? No. Hybrid search alone covers most days. But each layer got added because the previous layer fumbled a question I cared about - and since the whole thing is mine, adding a layer is a weekend project.

The night shift

The part nobody sees is my favorite part. While I sleep, memex works.

A maintenance cycle of about fifteen phases runs in the background, and the important thing about it: these phases are deterministic - plain code, no language model doing any thinking. The only AI they touch is the cheap embedding call, so a night's work costs cents. What the phases actually do, in order of how much I'd miss them:

• Keep embeddings fresh. Edited notes get re-embedded when their source is re-swept, and the cycle additionally renews vectors that have grown old (the phase is literally called embed-stale), so search never quietly goes out of date. Unchanged text keeps its existing vector - an edit only pays for the paragraphs that actually moved.
• Reconnect the web. If I renamed a project, split a note in two, or linked something new, the connections between notes get reconciled so the knowledge graph follows reality instead of drifting away from it.
• Take out the trash. Entries whose source is long gone get flagged as orphans so they can be swept out instead of haunting search results forever.
• Check the vital signs. The cycle records a snapshot of the corpus - how many documents, how much of it is embedded, what's pending - so trends are visible over weeks. The actual database backups are managed-Postgres routine, as they should be.

Then comes my favorite ritual: every night at 04:30 memex tests its own memory. It replays a golden set of questions - real questions I've asked before, with known good answers - and records how retrieval did: did the right note come back, and how high did it rank. Each run lands as a row of metrics, so if memory quality ever starts drifting, I see it as a falling number on a graph instead of a growing feeling that "search got worse lately." And I can cap what a run is allowed to spend, because I've learned to distrust anything that can burn money unsupervised at 4am.

When something does need attention - a stalled job, low embedding coverage, a pending migration - a built-in advisor ranks the problems by severity, and for most of them hands me the exact fix command. Less "something looks wrong," more "run this."

And for the curious: there's a second, optional night crew that I keep switched off most of the time. It's a chain of AI passes that reads recent notes and tries to distill them - pulling out atomic claims, grouping them into concepts, even proposing opinions with confidence grades attached, all written into its own separate store. It runs only in quiet hours and uses paid model calls - which is exactly why it's off by default in the public repo. Nice to have; not load-bearing.

I wake up, my phone shows the morning briefing (my own wiring again, a small script on the same server), and the brain has already done its chores. Honestly, it's better at maintenance discipline than I am. That was the point.

The AWS build, and its trade-offs

The infrastructure fits on a napkin, and I fight to keep it that way.

One EC2 instance - a $24/month ARM box. One small RDS Postgres. An EFS volume for runtime state, Secrets Manager for credentials, Bedrock for the AI calls. No Kubernetes, no autoscaling group, no load balancer, no message broker. A personal workload doesn't need an orchestrator; the entire runtime survives a docker compose up -d --build.

All of it is Terraform, sitting in the repo under an MIT license - take it apart, copy it, run your own:

# What `terraform apply` creates (illustrative - the repo's
# terraform is plain resources, not a module):
#   VPC + single EC2 (t4g.medium) + RDS Postgres (db.t4g.micro)
#   + EFS + Secrets Manager + IAM + optional CloudTrail
instance_type = "t4g.medium"   # ARM: half the price of x86
db_instance   = "db.t4g.micro"

A few decisions I'd make again:

No inbound ports. The EC2 security group opens nothing to the internet. Nothing. The only way in is a Cloudflare Tunnel - the sidecar dials out to Cloudflare, and my requests ride back down that connection. Shell access goes through AWS SSM Session Manager, so there isn't even an SSH port. None of this makes the box unhackable. It means the attack surface is a bearer token and Cloudflare's edge instead of an open-port buffet for scanners.

Private from whom? Worth being precise here, because "private" carries a lot of weight in this article. My threat model: SaaS vendors training on my notes, a product shutting down and taking my memory with it, careless token leaks. Not on the list: AWS itself - Bedrock processes my text, that's a trade I make consciously and you should too - and not a nation-state. Draw your own line. The point of self-hosting is that you get to draw it.

Layered damage control. The public access token rotates every morning, so a leaked token stops working within a day at worst - and there are more layers under it. Even with a valid token, public reads come back with note bodies redacted, and write operations aren't reachable from the public surface at all. And since retrieved notes eventually get fed to language models, memex neutralizes common instruction-injection tokens in retrieved excerpts before they reach a model - which lowers the risk from the well-known tricks, nothing more. Mitigations, all of it. But each one answers a specific failure I didn't want to explain to myself later.

Bedrock over API keys. Embeddings come from Titan v2. A small Claude Haiku handles query understanding. An optional Claude Sonnet tier does the deeper synthesis work, off by default. Bedrock is AWS-managed, but the calls are authenticated and scoped through my own account's IAM - no third-party API key floating around with my entire note history behind it.

And the bill, since somebody always asks: fifty-something dollars a month on paper, most of which AWS credits currently eat for me; the steady Bedrock share is coffee money, around thirty cents a day. My one splurge was a $23 afternoon of re-embedding the entire corpus with richer context. Worth it exactly once.

Scar tissue

I'll keep this short, but skipping it entirely would turn the article into marketing. The first version kept its database in an embedded Postgres on EFS - a hard SIGKILL ate my index one evening, and that's how RDS earned its place. I once built a full Cognito login setup before admitting that memex serves programs, not people at login forms - tore it out the same week. And retrieval still misses sometimes, when I ask in words I never wrote down. That's exactly what the nightly self-test is for.

Why build instead of buy

There are real products in this space - memory SaaS, notes apps growing AI features, vector-database startups. I went the other way, for three reasons:

1. Ownership is the feature. Years of decisions, projects, and half-thoughts is the most personal dataset I have. A memory product that shuts down, changes pricing, or "updates its privacy policy" isn't a tool - it's a landlord.
2. The interface is a standard. MCP means my memory speaks the same protocol AI tools are adopting across the industry. Betting on a protocol beats betting on any single vendor's plugin ecosystem.
3. The work is the education. Every hard problem in this project - chunking, ranking fusion, fact supersession, tenant isolation, cost control - keeps showing up in real conversations within months, wherever AI tooling is on the table.

For plenty of people, buying is the right call. If your notes live happily in one app and you trust the vendor, go live your life. But if you're the kind of person who reads Terraform for fun, github.com/timurgaleev/memex is waiting. Expect an afternoon to a day of Terraform, DNS, and reading docs.

How my week actually works now

Back to the Forward Deployed Engineer thing, because memex doesn't work alone. Three tools, three jobs, and my week runs through all of them.

vibekit holds the rules - how my AI agents are allowed to behave, what they must never touch, synced into every tool I use from one repo. vibestack holds the workflows - the repeatable loops I run daily: plan a feature, review a diff, ship a release, investigate a bug. And memex holds the memory. Behavior, workflow, recall. Each would survive the others' deletion, which is my working definition of good boundaries.

A normal day: my phone buzzes at 07:00 with a morning briefing my server composed on its own - calendar, mail, house status. On the train I ask the brain something I half-remember about a side project. Somewhere in a conversation - at work, or around a friend's business - someone describes a process that eats two months a year, and something clicks: I've seen this shape before, and my own stack is where I learned to recognize it. In the evening I open a session on a personal project, the agent asks memex where things stand, and we continue where I left off instead of starting over.

That last part is the real change AI brought to my engineering life. Before, my evenings-and-weekends work was throwaway - too little time, too much re-explaining, projects abandoned at the setup stage. Now the setup is remembered, the workflows are one command, and a one-person R&D department is a realistic thing to run before breakfast. Whatever judgment I have about AI tooling - what's actually worth deploying, where it breaks, what it costs - comes from running all of this myself, watching it fail on a Tuesday, and fixing it before work.

Takeaways

• AI tools without memory waste your time at scale. The re-explaining tax is invisible until you remove it; then it's obscene.
• Retrieval and reasoning should be separate. A brain that returns cited evidence works with any agent that speaks the protocol. A chatbot works with nothing but itself.
• Small infrastructure is a superpower. One ARM box, one managed Postgres, one tunnel. Boring enough to never think about, which is the whole point of infrastructure.
• Privacy is a spectrum you should place yourself on deliberately - decide who you're defending against before you decide what to build or buy.

The repo is at github.com/timurgaleev/memex - Terraform, docs, and every scar described above. If you build your own brain, or already run one, I genuinely want to hear how you solved the parts I got wrong. Eighty years after Vannevar Bush sketched the memex, the desk-sized memory machine is real, it costs less than a gym membership, and it fits in a t4g.medium.

What would yours remember?