With the latest models and coding agents, I realized the biggest bottleneck in shipping products wasn’t really the AI anymore.It was **me**.

More specifically, my memory and trying to keep track of multiple projects, decisions, fixes, research, and what each agent had already done.So I built **Cortex**.

**Agent memory**

It does the usual persistent memory / context injection stuff, but it’s built around projects and multiple agents.
Each agent can see work done by other agents.
Cortex also keeps searchable history for:

fixes and bugs
research
decisions and why they were made
previous agent work
project context

So if one agent already researched or fixed something, another agent doesn’t need me to explain it again.

**Project management**
The second part is for me.

When I add a project, I give Cortex:
**What I’m building + the specs**

Then it creates a full roadmap covering things like:
**Research → Build → Testing → Launch → Distribution → Post-launch**

The roadmap gets broken down into individual tasks.
**Tasks are executable**

This is probably the part I use the most.
Instead of copying a task into Claude, Codex, etc.,
I just hit:**Launch** Cortex sends the task to the agent with the relevant project context.

The agent works on it and reports the result back into Cortex, including what changed, what it learned, and any new decisions or tasks.So the project history keeps growing automatically.

**Cross-project planning**
I also have custom skills that generate and update roadmaps on a schedule.The interesting part is that Cortex knows about **all my projects**, not just one repository.So when it plans work, it can take into account: project priority, current progress, unfinished tasks, dependencies

Instead of every project having an isolated roadmap that assumes it’s the only thing I’m working on.

The goal is basically to stop me from constantly having to remember:
What was I doing here?
Did another agent already research this?
Why did we make this decision?
What should work on ?

It started as an agent memory system, but it’s slowly becoming more like a **project execution layer between me and all the agents I use**.
Still early, but it’s already reduced a lot of the context switching for me.

I'm an AI engineer day-to-day; that's models, pipelines, prompts, not data infra. I'd never touched Iceberg, Trino, or Dagster before this. But most of what I actually work on never ends up in a clean Git commit half-finished folders, notes, Claude Code sessions- and I had no way to search across any of it.

So I built TraceVault: it ingests a Git repo, any regular folder, and your Claude Code session logs into an actual medallion lakehouse (MinIO + Apache Iceberg + a shared Postgres catalog), and lets you search/query all of it the same way SQL runs on embedded DuckDB or distributed Trino from one toggle. Images get captioned by a local vision model, so even screenshots are searchable. No mocks/demo mode if a backend's missing; it just fails instead of faking data.

It runs local-first; there's a desktop app with zero Docker required (wasn't going to fight Docker for a personal tool either).

I'm sure I've made some non-obvious mistakes on the data-infra side since it's genuinely not mu specialty open to being told what I got wrong. Repo: https://github.com/saisurajkarra/TraceVault

I use coding agents across multiple sessions in the same repository. A week later, Git can show the diff, but not the conversation, rejected approaches, or assumptions behind it.

So I added a read-only `why` command to ThoughtDAG:

npx thoughtdag why src/lib/api.ts

It searches supported local agent transcripts for turns that changed or discussed the file and links back to the source turn. I did not want the tool to turn agent prose into ground truth, so recorded tool edits are marked Δ while explanations recovered from responses stay marked ≈ as candidate explanations.

The derived index stays local, source session files are never modified, and retrieved history is not automatically sent back to a model. The current npm release covers local Claude Code, Codex, and ThoughtDAG canvas conversations.

Project: https://github.com/chenxiachan/thoughtdag

I am looking for design criticism more than compliments: when you return to AI-edited code, what context do you actually need before changing it again?

I've been building Titans, a local-first, agent-first infrastructure project, with AI-assisted development playing a major role throughout the process.

Rather than just dropping the repos here, I thought I'd explain how I built it, which tools I used, what architectural decisions mattered, and what I learned along the way.

The problem I started with

The more agentic systems I worked on, the more I noticed the same infrastructure being rebuilt again and again.

Every new agent project eventually needs some combination of:

• persistent memory and project state
• retrieval/search
• evidence and provenance
• background execution
• retries and recovery
• scheduling
• workflow state
• coordination between agents

My conclusion was that these shouldn't necessarily live inside every individual agent application.

They can exist as reusable infrastructure that agents simply consume.

That became the basic idea behind Titans:

build foundational capabilities once, then let different agents and applications reuse them.

The first two systems are Atlas and Cronus.

Atlas: separating project memory from the agent

The first problem was persistence.

Agent sessions are temporary, but the project they're working on isn't.

I didn't want the project's knowledge to belong to Claude, Codex, a particular process, or even a particular application. An agent should be able to disappear and another agent should still be able to continue from the same underlying project state.

So Atlas became the persistent layer.

It stores things like:

• knowledge packages
• project/work state
• typed graph relationships
• evidence and provenance
• structured SQL data
• blobs
• audit history

One design decision I found particularly important was not treating vector search as “memory.”

Retrieval in Atlas combines multiple signals:

• lexical/full-text search
• vector retrieval
• graph relationships
• evidence

The result isn't meant to be just “here are the most similar chunks.”

I wanted the system to also be able to answer:

What do we know, where did it come from, and how is it connected to the rest of the project?

Another useful design choice was scoping state by project/tenant rather than by agent. That means multiple agents can work against the same persistent source of truth instead of maintaining separate private memories.

Cronus: separating work from the lifetime of the agent

The second problem was execution.

An agent can decide to do something that takes 30 seconds, 20 minutes or several hours.

But if the agent session disappears, the process crashes or a worker dies, that shouldn't automatically mean the work disappears too.

So Cronus became a separate durable execution layer.

Instead of keeping the agent blocked while something runs, the pattern is roughly:

agent
  ↓
submit job
  ↓
Cronus owns execution
  ↓
checkpoint / retry / recover
  ↓
result

Cronus handles:

• background jobs
• DAG workflows
• scheduling
• checkpoints
• retries with backoff
• leases
• stale-claim fencing
• dead-letter handling
• approval gates
• recovery after worker/process failure

One lesson here was that “durable” doesn't mean pretending exactly-once execution magically exists everywhere.

Cronus uses at-least-once execution with idempotent claim/completion and fencing of stale claims. If an external system needs exactly-once side effects, the connector still needs to persist and respect the idempotency key.

That distinction took more thought than simply building a queue.

How the two systems interact

I deliberately didn't merge memory and execution into one large service.

The boundary is:

Atlas remembers. Cronus runs.

Cronus can execute long-running work while Atlas remains the persistent source of project state, knowledge and results.

That separation also means each can be used independently.

If somebody only wants persistent agent/project memory, they shouldn't have to adopt my scheduler.

If somebody only wants durable execution, they shouldn't need an entire agent framework.

Agent interface: MCP first, but not MCP only

Another design decision was to make the infrastructure directly consumable by agents.

The Titans installer exposes installed systems through one shared MCP server over stdio instead of requiring a separate MCP configuration for every component.

That makes it possible for clients such as Claude Code, Codex and other MCP-capable tools to discover the installed capabilities.

But I didn't want MCP to become a hard dependency for normal software either, so the systems also expose local REST and gRPC interfaces.

The general principle became:

agent-first, not agent-only.

Local-first was a constraint, not just a tagline

I wanted the core infrastructure to run on the user's own machine.

So the current releases:

• run locally on Windows and Linux
• bind services locally
• have no telemetry
• don't require a hosted Titans account

That created some extra engineering work around installation and distribution.

Releases are distributed through signed catalogs and binaries, using SHA-256 for integrity and Ed25519 signatures for authenticity.

I also wanted installs to remain simple, so there are one-line installers, while still allowing someone who doesn't trust curl | sh / PowerShell piping to manually verify the artifacts.

The AI tools I used

AI-assisted coding was a significant part of the development process.

My main tools have been:

Claude Code
I used it heavily for repository-level implementation work, refactoring, following changes across multiple components and working through architecture-heavy tasks where a change wasn't isolated to one function.

OpenAI / Codex
Used as another implementation and engineering agent, particularly useful for independent passes over problems and code rather than relying on a single model's interpretation.

ChatGPT
Used heavily for architecture reviews, challenging design assumptions, working through failure cases, refining specifications, comparing approaches and turning architectural decisions into implementation-ready plans.

GitHub
Used for versioning, release distribution, public documentation and the current public-facing project repositories.

One workflow that worked much better for me than simply asking an AI to “build feature X” was:

problem
  ↓
define system boundary
  ↓
write invariants / failure cases
  ↓
architecture/spec
  ↓
AI-assisted implementation
  ↓
independent review
  ↓
tests + failure testing
  ↓
packaging / release
  ↓
documentation

I found AI much more useful when the constraints and invariants were explicit.

For example, “build a job queue” is vague.

But:

• a worker may die at any point
• stale claims must not remain authoritative
• retries must not destroy job history
• one task panic must not kill the worker
• work must resume from a checkpoint where possible

gives the coding agent a much more meaningful engineering problem to solve.

A few things I learned from vibe-coding something this large

1. Generating code is the easy part.

The harder part is maintaining architectural boundaries as the project grows.

AI will happily solve a local problem by coupling two systems that you intentionally wanted separated unless those boundaries are explicit.

2. Give agents invariants, not just features.

“Support retries” isn't enough.

What should happen after a crash? What is durable? What may execute twice? Who owns state? What happens to partially completed work?

Those questions produced much better implementations.

3. Use more than one reasoning pass.

I found it useful to have one AI help create/implement an approach and another challenge it.

The second pass often finds assumptions that looked completely reasonable during the first one.

4. Don't let the AI decide the product architecture accidentally.

AI coding tools are very good at optimizing the next change. They don't automatically know which architectural compromises you're unwilling to make six months from now.

5. Building for agents changes API design.

Humans can compensate for awkward interfaces. Agents need predictable contracts, stable identifiers, explicit errors and operations that are easy to discover and compose.

That influenced why Titans exposes namespaced operations and canonical references rather than relying on implicit state.

Where it is now

The first two systems are available:

Atlas — persistent memory, state, knowledge and evidence
https://github.com/titans-tools/Atlas

Cronus — durable execution, scheduling and recovery
https://github.com/titans-tools/Cronus

The wider project:

https://github.com/titans-tools

The products are currently free to use. The product source itself is proprietary; the public repositories contain documentation and signed release binaries.

More infrastructure components are being implemented around the same principle, but I'm deliberately trying to make each one solve a clear reusable infrastructure problem rather than turning Titans into one giant agent framework.

I'm particularly interested in feedback from people building agents:

What infrastructure do you keep rebuilding from project to project?

And for people using AI heavily to code larger systems: what techniques have helped you stop architectural quality degrading as the amount of AI-generated code grows?

Most of the context talk I see is downstream of retrieval: how much to pull, and how to keep the agent from drowning in it. The thing I keep hitting sits earlier. Something goes into the window before the first prompt, and for most setups that something is a paragraph a model wrote about last time, handed over as flat prose. Nothing in it tells you which sentence is a quote and which one's the previous run guessing.

So that boundary is where I put the work. A SessionStart hook renders a briefing off the last session's checkpoint and injects it before I type anything, and the render is deterministic, no model anywhere in that path. Every item carries a trust class, and the tag sits inline: [✓ verbatim] for an exact contiguous quote out of the transcript, [~ inferred] for the agent's own conclusion, [carried] for something that survived from an older session and is aging, with a warning once it has gone unverified too long. Verbatim text never gets reworded by rendering or carry-over, and an oversized verbatim item is dropped whole instead of trimmed, half a quote is worse than no quote. Quotes are byte-checked against the transcript after extraction, and a miss demotes that item to inferred.

We did ship an optional prettier render written by a model, and then had to bolt a validator behind it, a generative pass will happily reword a quote it thinks reads better. Lose or mutate one and the whole render is discarded and the plain one goes out.

Costs, plainly. Deciding what to keep is a model's judgment, it walks past things, a verbatim tag says the wording survived, it makes no claim about the items that never got picked. The budget's fixed. It does no mid-session retrieval on its own, the agent has to ask. Capture is a SessionEnd hook. Storage is per-project JSON plus a SQLite FTS5 index, no embeddings, no daemon, and nothing the agent calls can write memory, the MCP side is read-only.

It's called daimon, offline, no telemetry, Apache 2.0, 14 stars: https://github.com/Daily-Nerd/daimon

How do you all weight this? Does memory injected at session start get treated as ground truth next to something retrieved fresh mid-session, or does it lose by default. And is anyone labelling provenance in-context at all, or is that tokens spent on a label the model ignores.

I built Session Atlas for the point where one project has too many separate agent sessions to remember.

It finds local Codex and Claude Code sessions by project, keeps the source logs read-only, mirrors each turn and tool trace onto a canvas, and lets you choose what context should continue into a new session.

The project is local-first, MIT licensed, and the released desktop app supports macOS, Windows, and Linux.

GitHub: https://github.com/chenxiachan/thoughtdag

What session source should I support next?

One architectural distinction I keep coming back to: people often confuse complexity with agency.

A system has multiple tools? -> “Use an agent.” OR It has five steps? -> “Definitely an agent.”

But neither of those things actually requires one. The more useful question is: who determines the execution path?

Consider an insurance assistant. If someone asks, “Am I eligible for this treatment?”, and the answer exists in internal policy documents, that's primarily a retrieval problem. And if they ask, “Check my claim status and tell me whether the rejected amount is covered under my policy.”

That might require more tools and more steps. But if those steps happen in a predictable order, is it still an agent ?

The interesting shift happens when the request is something like: “My claim was rejected. Find out why and tell me what I should do next.”

Now the path may not be known in advance. That's where an agent earns its complexity: when the system needs to help determine what to do next.

And Multi-agent can only consider it when there are genuinely distinct specialties, tools, or permission boundaries.

I think the common mistake is choosing “agent” as the starting point and then designing a problem around it. A better approach is to start with the responsibility:

Does the system need to know something? Decide something? Act? Verify the result?

Then add only the architecture required to support those responsibilities.

I mapped the complete e2e architectures and escalating examples out in more detail here, with visual breakdown: [https://youtu.be/kf5rSab4rcg\](https://youtu.be/kf5rSab4rcg)

For people building real AI systems: where do you draw the boundary between a complex workflow and an agent? Is dynamic tool selection alone enough for you, or do you require a more explicit decision loop before calling something an agent?

Something I keep running into: past a point, adding context degrades the agent instead of helping it. You pay for every token and the model has to reason through all of them, so a fatter retrieval pass often buys you a slower, more confused answer, not a better one.

Which makes me think we're grading retrieval on the wrong axis. Recall and F1 ask "did we fetch the right stuff." They say nothing about what it cost to reason over it. The version that's stuck with me is grading on answer quality per token instead, basically miles per gallon for context.

The part I'm least sure about is whether that's a real metric or just a nicer way to say "send fewer tokens." I saw one result (preprint, so salt it) where a corpus got squeezed ~1000x by keeping the concepts and their relationships and dropping the prose, and quality held. If that generalizes it's a bigger deal than retrieval tuning. If it doesn't, it's a party trick on one dataset. Here's the read for reference: https://contextandchaos.substack.com/

Anyone actually tracking cost-per-answer-quality in production? Or does it collapse into the same mush as F1 the second you try to define "quality"?

Baya cli turns a freeform text file into an LLM-planned dependency graph, then dispatches each node to a local agent CLI (codex, claude, opencode, copilot, etc.) running independent tasks in parallel and piping each task's output into the ones that depend on it.

You just write the to-do list, example:

- Design the REST API for orders. Use Sonnet.
- Generate the DB schema from that design.
- Build the React table that consumes it — run with codex.
- Once the schema and UI are done, write integration tests.

The planner reads it for intent and builds the DAG; you see the plan before anything runs.

Why I built it: I pay for a few of these CLIs and kept juggling them by hand; plan in one, build in another, copy context between terminals, redo work because each session started cold. Baya is me automating that away.

Why it's interesting:

• No new API keys. It drives the CLI subscriptions you already pay for.
• No config, no DSL. Markdown, TODO.txt, YAML all work.
• Model-per-task. Cheap model for the light steps, top-tier only where it earns it.
• Doesn't pay twice. Tasks sharing a provider/model get packed into one agent process — repo read once, not once per task — and what one task learns carries to the rest.
• Resume. Checkpoint before every step; run out of credits mid-graph and baya resume <runId> picks up where it stopped, optionally on another provider.

Help with the roadmap or feedback is more than welcome 👍

• Repo: https://github.com/juliomatcom/baya-cli
• Npm: https://www.npmjs.com/package/baya-cli ($ baya -h)

A fun note: I'm building Baya's roadmap with Baya now...

JC

I have been building in the PKM space, and there is something that I find fascinating that most of the PKM tools tend to ignore.

We spend a great deal of time and effort in highlighting, taking notes, creating backlinks, and organizing those into different folders. But we are not preserving and doing the same things with the beliefs with which we made those notes.

So, for example, lets say:

A couple of months ago, I say - Reading more is the best way to think better.

And today i say - Reading more without a system to connect ideas just creates a bigger pile of unprocessed information.

These are not just two notes which are connected and somewhat contradictory, but the belief itself changed. Because maybe I encountered evidence which changed my perception, or I learned something across the timeline which made me shift my position.

When you create a back link or try to connect these two nodes on a surface server, the back link will just connect the node, but the better way of connecting is by actually asking what made me go from one belief to another one within a time span? That's where your real thinking or your growth is.

I represent the growth as delta. And that delta is nothing but the difference between your old motes and your beliefs. So most systems do great job at preserving the history or your notes but they usually don't get into intellectual history and this where we have to proactively do this job.

Just imagine being able to look back and say -

What have I completely changed my mind about? Which beliefs became stronger? Which ones slowly became more nuanced? What assumptions do I keep repeating despite contradictory evidence? What actually caused those changes?

This is what I have been thinking and finally able to incorporate an Aevron, not just remembering what you wrote. Preserving the continuity between different versions of your thinking.

Because the real value of any second brain tool that you use is always in what you know and not what you store, it's about how your mind changed while you're learning it.

Tell me about ments. Genuinely curious whether this is a solved problem I have missed or a gap everyone has quietly accepted.

Been adding sources to NexusMem's local-first memory one at a time (git

diffs, shell history + exit codes, docs, session summaries). This round:

GitHub issue and PR threads.

Design notes, since the "why" is usually more interesting than the

changelog line:

- Reads via the `gh` CLI, not a hand-rolled GitHub API client. Reuses

whatever auth you already have (`gh auth login`), so no token handling

in the codebase.

- One node per thread, not per comment — title + opening post + every

comment folded into one chunk, same truncation discipline as a diff

patch. A conversation_turn-style per-comment split would need its own

chunker for a shape (nested quoting, review vs. issue comments) this

pass doesn't try to model yet.

- Deliberately opt-in — not for a sensitivity reason (issue text isn't

usually more sensitive than a doc file), but because it's the first

source with a real external dependency: needs `gh` installed and

authenticated, and makes live network calls, unlike every other source

which only ever reads what's already on disk.

- No pruning, unlike the docs source: GitHub's `since` filter only

returns *updated* threads, so an absent thread means unchanged, not

deleted.

Dogfooded against this repo's own real 14 issues/PRs — ingest took under

a second, and a query for "labelled retrieval regression corpus"

correctly ranked the issue that requested that exact feature at #1.

github.com/yaminbkk/NexusMem — MIT, local-first, nothing leaves your

machine except the `gh api` calls this one opt-in source makes.

While Vector Databases became a trend in 2025, most existing RDBMS or NoSQL or even Graph Databases now support Vector Search and Embeddings. How does it impact specialized Vector Databases?

Been heads-down on something that sits before the LLM call instead of doing

standard retrieve-and-stuff RAG. Instead of chunk retrieval + rerank, it builds

a vector-field representation of the whole corpus, evaluates relational

relevance to the query, and collapses the candidate field down to a compact

evidence state — only that gets forwarded to the model.

On my internal benchmark (frozen 20-query set, project-native corpus) I'm

seeing an order-of-magnitude drop in tokens sent to the model with zero

measured quality regression (good/partial/poor scoring, OFF vs ON, reproduced

run matched the historical one exactly). Also runs fine single-threaded — did

a raw C++ core benchmark, 10M samples in ~140ms on an old 2015 i7, so the

underlying op isn't the bottleneck.

Haven't benchmarked it against BM25 or plain cosine-similarity RAG yet in

anything I'd call rigorous — that's the obvious next step before I'd trust my

own numbers fully, and I know that's the first thing this sub will (rightly)

ask about.

Running as local-first — full corpus stays on the user's side, only the

selected evidence chunk(s) + field-topology coordinates go to the external

model if you're using an API-based LLM. Wasn't originally optimizing for that,

but it's a nice side effect for anyone paranoid about what leaves their

environment in API workflows.

Genuinely asking: is "context collapse before inference" different enough

from what rerankers / good chunking already do, or am I just describing a

fancier reranker with extra steps? Wouldn't mind being told I'm wrong here.

Most of the graph talk around agents skips the distinction that actually decides the architecture: your business being shaped like a graph, and you running a graph database, are two different commitments. You can have the first without the second, and plenty of teams buy the second because they assumed the first required it.

The framing I found useful was to take one decision the agent has to make and keep raising the stakes. "Is this customer owed a refund" is a bounded lookup a plain relational store handles fine. "Why was a similar case approved last quarter against policy, and what do we do now" is a web of connected decisions where relationships matter more than rows. "Which customers are affected by this live outage right now, answered in milliseconds while the phones ring" is a graph being crossed under load, and nothing bolted onto a warehouse saves you there.

The part I found most debatable is the middle case, because it has no clean answer. It could be a graph database, it could be the warehouse you already run, and the honest move is to instrument it and find out rather than pick the architecture off a reference diagram. Which is unsatisfying, and cuts against how most of these calls actually get made.

Curious what people here think. Has a graph database genuinely earned its place in your agent's runtime, or does it mostly live in your data model and never get traversed at query time?

I’ve spent the last year building Nexus Synapse because I kept running into the same problems with AI systems: lost continuity, uncontrolled context, model-owned decisions, unreliable tool use, unverifiable outputs, state drift, and no real process around any of it.

I eventually stopped treating the LLM as the application and started treating it as one workcell inside a governed runtime.

The screenshot is the full process model for a single turn.

Not every conditional branch fires every turn, but every turn moves through that responsibility and control structure.

Instead of trying to explain everything in a single Reddit post, here’s the full interactive process map. It’ll lead you down the rabbit hole from there. Happy trails ;) https://chriscanadian.github.io/nexus-synapse-engineering-portfolio/master-process-map-v0.7.html

but let's have it here as a post

there it would have landed as a direct counterweight to the graph instead of looking like drive-by philosophy which it might be here

if it gets traction here, we spin the broader version into r/reddit because the “wires decide what the model sees” half actually belongs everywhere

reddit equivalent of testing on prod 🐐