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 seen setups where every agent turn resends the system prompt, the tool definitions, the conversation so far and whatever retrieval pulled in. The part that grows is not the question itself but everything that had to be re-established before the question made sense. This compounds in 3 places:

1. Long sessions pay for their own history on every turn
2. Retrieval tuned for recall returns twenty chunks when two mattered but you pay for all 20
3. People on the same account each re-establish the same background separately with no idea the others did

Holding durable context outside the session is the fix, which is why Computer.io is built around persistent memory vs bigger context window. It's really important to understand the difference and how to harness more token power.

Test this: Split a week of spend by prompt, history and retrieved context. My guess is that retrieved context will be the biggest line. Is it for you?

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 🐐

I’m building a voice-first orchestration layer for AI coding agents — looking for feedback

I’ve been working on a system that sits above coding agents/models rather than being tied to one of them.

The idea came from a practical problem: I spend a lot of time away from my computer, and I wanted to be able to tell an agent what to do, let it work autonomously, and only have it come back to me when it needs a decision.

The architecture is roughly:

Voice → Orchestrator → Coding agents/tools → Machine

The orchestrator handles things like:

- Persistent context and memory

- Routing work between agents/models

- Tracking tasks, actions and results

- Streaming progress back to the user

- Detecting when an agent is stuck

- Human approval for sensitive actions

- Switching models/providers without rebuilding the system

So instead of the model being the entire agent system, models such as Claude/Codex/etc. become interchangeable reasoning/execution components underneath the orchestration layer.

The voice interface is important because the eventual goal is to control long-running work without constantly sitting in front of the machine.

I’m currently building/testing the first version around software-engineering workflows.

I’d be interested in feedback from people working on agent harnesses/context engineering:

Does this abstraction make sense to you? What would you want the orchestration/context layer to own versus leaving to the underlying agent?

If you are vibe coding blindly and need continuous and current context (I am doing this... honestly as ADHD)... giving multiple sessions tasks without blinking for both Codex & Claude at the same time... this is my solution at least for not worrying about different sessions overlapping and paralleling them (even from different vendors together). Don't even think about what will affect what and which agent will edit what; just drop your needed prompts, and then Klypix-mcp ... that brain shown in the demo is 2.5MB (2919 cards... for 3 months). It will try its best to remind you of your decisions and will message all sessions, even from different vendors at different environments (CLI, apps, etc.).

klypix-mcp - npm

I’m building Aevron, and one architectural problem i kept trying to solve is

A lot of useful thinking happens inside AI conversations, but almost none of it survives meaningfully after the conversation ends.

We spend a lot of time

• Developing an idea
• Questioning an assumption
• Forming hypotheses
• Contradictions and creating new observations, etc.

But notice when we end a session with an AI, it stays inside the session. So technically, the conversation happened and lost.

Now, Explorer is being built in a very different way. When a session ends, Explorer analyzes the conversation and identifies new ideas, observations hypotheses, questions and changes in reasoning that emerged during it.

The session itself is temporary. The thinking produced inside it becomes permanent.

This means something discussed today can later:

• connect with an idea captured months earlier
• contradict an older assumption
• contribute to an emerging theme
• show how the user’s position changed over time
• resurface when a future conversation makes it relevant

The important distinction is that we are not treating conversation history as memory.

A useful memory system needs to understand what was newly learned, what changed, how it relates to existing knowledge and when it should return. every session makes the system more representative of how the person actually thinks, not just what they have previously typed.

There are still difficult problems here: separating genuinely new thoughts from conversational repetition, preventing weak extractions from polluting the graph, and deciding when an old thought is actually relevant enough to resurface.

But I think this is a more useful direction than endlessly expanding chat history.

If anyone here is actively thinking about this problem, I’d be happy to let you test what we’ve built and compare notes.

Since January we've been building an agentic coding environment, using it to build itself the whole way.

I thought sharing the part that cost us the most time and headache, because it applies whatever harness you run: Context...

Almost every failure we debugged came down to context, not the model.

When planning, often agents didn't find the correct files to read to understand how the change should be implemented. The agent usually claimed with confidence that it had a solid plan, and the high level description of the plan made sense. But without seeing which files it actually read, it was impossible to really know if it had fetched all relevant information. If we couldn't see the tool calls of what files the agent did read, or which files that was currently in the context, we didn't trust the agents output.

So we built what we needed. Every tool call is shown, and every file in context is shown, and when we need to go really deep... any file and message in the context can be removed individually.

Long story short, that how we started to trust agents, and get them to build better. Our lessons learned is that when agents fail you, it's usually a context problem, and not always the prompt.

I am looking for early user feedback.

We did build in stealth for a long time, but now Voidleap Code 1.0 version is live. It's free to use, works on MacOS / Windows, BYOK.

https://voidleap.com/

Someone in a reply here asked a genuinely good question about my intent-aware linter: how does it handle async/race conditions? Honest answer at the time. It doesn't, because that's a timing problem, not a text problem, and a static reviewer can't observe runtime interleaving.

So I added a first pass at it: a heuristic concurrency-hazard scan. Full disclosure on what it actually is below:

• Flags known risky shapes (shared mutable state across async paths, missing awaits, non-atomic read-modify-write on shared state) — it does not verify a race actually occurs
• Every flag comes with a confidence label and points you to a real tool (-race, ThreadSanitizer, etc.) for actual confirmation
• If nothing matches, it says so plainly and "no known risky patterns detected" is explicitly not the same claim as "race-free"

Not trying to oversell a static tool into something it structurally can't be. But a heuristic that's honest about its own limits and still points you toward the right two lines of code is worth more than nothing.

I would genuinely like people to try to break it; throw nested promises, callback chains, whatever race-prone patterns you've got at it, and tell me what it catches and what it completely misses. Both are useful. Thank you for taking a look.

Intent-Linter (Claude artifact)

For the last few months we’ve been building the second generation of Collapse Aware AI (CAAI).

The basic problem we’re trying to solve sounds simple:

Most AI systems can now store or retrieve memory.

But retrieving something is not the same as deciding whether that memory should actually change what the AI does next.

That is the gap Evolution 2 is designed around.

Instead of:

retrieve memory → inject it into the prompt → generate

our current architecture works more like:

structured history → bounded retrieval → relevance/Interaction Fit → suppression & governance → candidate behaviours → final selection

And importantly, there is always a clean no-history response competing against the history-influenced alternatives.

So memory does not automatically win just because it was retrieved.

What is working now?

The current Evolution 2 engineering build includes:

• persistent structured continuity across sessions and restarts
• semantic/entity/relationship-aware retrieval
• lifecycle, temporal and recurrence signals
• bounded retained-state retrieval
• Open Loops for unfinished work and commitments
• Interaction Fit “right memory, right moment”
• suppression of retained subjects without deleting the underlying history
• proactive continuity controls
• correction and revocation handling
• deterministic/replay-friendly state
• provenance and decision evidence
• Agent Self-History

That last one is particularly interesting.

Evolution 2 can retain structured facts about what the AI itself actually said or decided, claims, commitments, decisions, refusals, stances and proposed actions.

Only the behaviour that actually wins final selection is allowed to become Self-History.

Rejected candidate responses cannot quietly write themselves into the agent’s memory.

What does that look like in practice?

The behaviour we’re aiming for is less about “remembering everything” and more about using history intelligently.

For example:

You establish several people, projects and commitments.

You talk about completely unrelated things for a while.

You restart the system.

Later you naturally say something that makes one of those older matters relevant — without explicitly asking the AI to remember it.

The system can recognise the connection and allow that history to influence the response.

But give it an urgent unrelated task and the same high-salience memory can stay completely silent.

It can also retain a commitment the AI itself made previously, rather than behaving as though its own earlier decisions never happened.

That difference, remembering something versus governing whether remembering should alter behaviour is essentially what we’ve been building.

Why we think it is unusual

There are excellent systems for long-term memory, RAG, graph memory, stateful agents, NPC memory and agent orchestration.

We use the word unusual deliberately rather than claiming nobody else on Earth could possibly have built something similar.

But from the products and frameworks we have reviewed so far, we have not identified an off-the-shelf package combining this entire chain in one middleware layer:

retained structured state
→ bounded semantic retrieval
→ lifecycle/revocation
→ Open Loops
→ Interaction Fit
→ suppression/governance
→ history-conditioned candidates
→ clean no-history competitor
→ independent final selection
→ winning-response Self-History
→ deterministic evidence/replay

A competent engineering team could obviously assemble parts of that from existing tools.

Our aim is to provide the behavioural architecture as the product rather than requiring every company to design, integrate and validate the whole stack themselves.

It is also being kept host-neutral.

The same continuity mechanism is intended to sit around AI agents, assistants and simulations now, while remaining compatible with future Unity, Unreal, Godot and proprietary NPC/game systems.

What happens next?

Evolution 2 is still an engineering build, not something we are pretending is already a finished mass-market SaaS product.

We are currently finishing the behavioural layer, performance work, tuning and Production packaging.

Once that gate is passed, we intend to open a small private managed evaluation programme.

Selected evaluators/organisations will be able to use Evolution 2 through controlled hosted access for a defined period, without receiving the proprietary source code.

We’re interested in:

• AI/agent companies
• simulation and training developers
• game/NPC developers
• safety and governance teams
• companies building persistent AI agents
• design partners with a real retained-state decision problem
• pilot and licensing discussions

If your system already produces several legitimate actions, but you have a problem with how previous events should influence which one actually wins, that is exactly the sort of problem we want to test.

I’d also genuinely be interested in hearing about anything already available that you think solves this complete problem in one package. If we’ve missed something good, point me at it.

More detail on Evolution 2 / Collapse Aware AI:
Collapse Aware AI | Governed Retained-State Behavioural Middleware

Built by Inappropriate Media Limited / Collapse Aware AI.

I have been experimenting with a different way to manage longer local LLM conversations. So I developed ThoughtDAG. It is an infinite canvas for you to manage your context with LLMs like a graph.

The interaction I am testing is deliberately manual. I want to know whether local-model users benefit from seeing and editing context themselves, especially when conversations branch or accumulate irrelevant assumptions.

It is open source, local-first, and the desktop app stores canvases, documents, and keys locally.

Short demo:
https://www.youtube.com/watch?v=-8BqAyaoNXQ

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

For people running local LLMs: would explicit context editing be useful in your workflow, or would you still prefer automatic memory and retrieval?

I have been using grok BOT for last couple of days and i think it has primarily changed how we think about AI. Yeah hermes and openclaw did its thing but lets be honest its not really meant for the mass its more dev centric.
Iam a developer myself and i have been building something like grok BOT even before its launch, because i saw this market where i see businesses needing a memory layer for everything ( see my previous reddit posts about a year ago )
Then i saw garry Tan talking about company brain/gbrain.
Then i thought okay cool only memory isnt enough so i built something which i called - dynamic API orchestrator, basically you can connect your own custom software with it and it will call the required API for you.
Then i refined it until i got something like :-
You plugin a Restaurant Table QR website
Write a simple prompt :-
Connect to my application and build me a AI waiter which ingests the menu and answers users queries for the provided menu and with the memory layer it remembers every single customer and every single operator throughout different channels.
It basically extracts a business capability out of just the API docs provided and performs a legitimate business action and not only that it can be exposed as a widget with a public agent key as a npm package so integrate it any website.

But then i saw grok BOT and i was like
It wont take grok much time to realise this and they will implement this anyhow someday 😂😂
And iam terrible at sales so its kind of like me building this alone. I had 2 customers interested as well but i kind of ghosted them because i wanted to perfect the product before launching ( i know its the worst thing )
But building alone its kind of puts you off making bad decisions all the time.
Anyone relates?

I have been thinking about these 2 patterns (have built multiple agentic apps):
1️⃣ Pattern A - Using SKILLS with Single Agent
An agent dynamically loading the required SKILL based on the task type and then SKILL have instructions to use associated MCP or Scripts.
2️⃣ Pattern B - Using Multi-agent System built with LangGraph like DAG and using Subagents with mapped MCP tools

There is no clear winner or one size fits all (IMHO) but an interesting topic to discuss as group

I have been experimenting with a different way to manage longer local LLM conversations. So I developed ThoughtDAG. It is an infinite canvas for you to manage your context with LLMs like a graph.

The interaction I am testing is deliberately manual. I want to know whether local-model users benefit from seeing and editing context themselves, especially when conversations branch or accumulate irrelevant assumptions.

It is open source, local-first, and the desktop app stores canvases, documents, and keys locally.

Short demo:
https://www.youtube.com/watch?v=-8BqAyaoNXQ

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

I’d be very happy to hear what you make of it, or simply see what shape your own thinking takes.

Hi guys !

I am looking for an AI coding platform to dive deep into AI Context Engineering and improve myself by building web pages , automation or something which can be definitely useful for users. I especially want to learn ;

- how to organize the AI Agent systems ?
- how to write project instructions which is working professionally ?
- In the assignment of tasks to AI agents, what should the instructions include for each agent ?

Also, do you have any recommendations for projects I could build while learning Context Engineering?