Hey folks 👋

We just open sourced TrueForge, our vendor-neutral agent harness for building general-purpose agents.

It handles the runtime pieces that get painful quickly : context management, tool/MCP execution, subagents, sandboxing, approvals, persistent state, and more.

We also benchmarked the harness itself. With the same Opus 4.8 model, TrueForge delivered a similar solve rate at ~30% lower cost than Claude Managed Agents. Switching to an open model pushed that to ~75% lower cost on the same benchmark.

Would love feedback from people building agents.

⭐ Star the repo: https://github.com/truefoundry/trueforge

📖 Read the launch article: https://x.com/truefoundry/status/2090081376330715176

As someone using AI agents for the last one year to run my company, I need them to understand company context, not just return related text chunks.

The problem: ask "what breaks if we deprecate the v1 API?" and standard RAG gives you four chunks from a design doc, a postmortem, a Slack thread, and meeting notes. The model has to still figure out on its own that the postmortem describes the same API the design doc deprecates, and that someone already posted a migration timeline in Slack.

I built a tutorial using HydraDB that adds graph context on top of vector retrieval. Instead of just ranked text, you also get relationship edges: billing-service DEPENDS_ON payments-api-v1, payments-api-v2 REPLACES payments-api-v1. Model gets structure, not a reading list.

The useful part was bring-your-own-graph. You declare service dependencies and team ownership explicitly instead of relying on LLM extraction. For structured data you already maintain, the graph is deterministic.

It also supports per-user memory. Same question, different depth depending on who's asking. An engineer gets migration mechanics. A manager gets timelines and ownership.

Runs end to end in 30 minutes with synthetic data.

Repo with full working code: https://github.com/manveer/company-brain-tutorial
Tutorial: https://hydradb.com/blog/build-company-brain-ai-agents

We’re building Elvara AI from zero, and we’re looking for a founding engineer to join us.

Elvara is an early-stage AI project built around one idea:

“Understand First. Act Second.”

We don't want to simply build another chatbot.

We want to explore an AI that can:

• Understand the user's actual goal

• Keep track of important context

• Decide what information matters

• Research when necessary

• Reason before acting

• Help both developers and everyday users

Right now, Elvara is still in the early development stage.

We do NOT have a finished AI product yet.

That's exactly why we're looking for someone who wants to build it with us.

Who we're looking for

You don't need to be an AI expert.

We're interested in people who:

• Enjoy building things from scratch

• Are curious about AI and software

• Can think independently

• Like experimenting with ideas

• Are comfortable with unfinished projects

• Actually want to contribute, not just receive instructions

Useful experience:

• Python

• LLMs

• AI agents

• Backend development

• APIs

• Git / GitHub

• C++ / Rust / JavaScript / TypeScript

What you'll do

You may work on:

• AI model integration

• Context and memory systems

• Coding capabilities

• Tool calling

• Backend infrastructure

• Experiments and prototypes

The exact direction will evolve as we build.

About us

Elvara AI Studios is a very early-stage two-person team.

We're starting small and building from the ground up.

Our goal is not to immediately become another giant AI company.

We want to build something genuinely useful, test it with real users, learn from failures, and grow from there.

If you're interested in helping build Elvara from the beginning, we'd love to hear from you.

Contact: ckpo1239@gmail.com GitHub: https://github.com/Electric-light-hub/Elvara-AI

Hi guys,
We’re working on an open source project called Extra, and we’re looking for AI engineers or people how interesting in ai agents. If it’s make you interested our issue list is waiting.
https://github.com/extra-org/extra

The more I learn about agents, the more I see the LLM as just one part of the system.

The interesting part is what happens around it.

Give the model tools, and it can take action.

Give it memory, and it can carry useful information forward.

Give it context, and it can understand what is actually happening.

Give it a goal, and now you have something that can work through a problem instead of simply answering a question.

Think about a failed data pipeline.

A chatbot can explain possible reasons for the failure.

An agent could potentially inspect the logs, check recent code changes, look at the data, identify the problem, and recommend what to do next.

That shift from answering questions to getting work done is what I find most interesting.

But it also raises much harder questions.

What should the agent be allowed to see?

What should it be allowed to change?

How do we verify its decisions?

And who is responsible when it gets something wrong?

I’ve been thinking through these ideas while learning more about agent systems, and I put together a simple explanation of the building blocks:

AI Agents Explained: LLM, Tools & Memory (Anyone Can Understand This)

https://youtu.be/cR04pXTbszQ

I’d love to hear from people actually building these systems.

What makes an AI agent genuinely useful in your experience, rather than just another impressive demo?

I’ve been experimenting pretty heavily with AI coding agents, and I kept running into the same pattern:

The model was often capable enough to do the actual coding.

The failures were happening around the model.

Things like:

• making important decisions without asking
• carrying too much irrelevant context
• forgetting decisions from previous sessions
• not using the right specialist capability
• modules working independently but breaking when integrated
• saying something is “done” without enough verification

So instead of trying to solve everything with a bigger prompt, I started building a system around the agent.

I called it Escapement.

The basic loop is:

Specify → Route → Execute → Verify → Persist

It’s a repository-native harness that sits around coding agents rather than replacing them.

The core idea is:

Don’t upgrade the model. Upgrade how the model works.

Current v1 is at v6.3.0 and includes:

• 35 native skills
• 58 specialist capability strengths
• 143/143 unit tests passing
• 22/22 routing evals passing
• 4 real-use case studies
• bounded, phase-specific context
• persistent project and multi-module state
• deterministic verification evidence
• security + UI quality gates
• observability
• harness ablation

One thing I’m actively trying to avoid is turning this into a giant framework full of rules nobody has evidence for.

The philosophy has gradually become:

Observed failure → smallest useful mechanism → regression evidence

If agents repeatedly ignore something that can be checked mechanically, I’d rather build a deterministic check than add another paragraph to the prompt.

I’ve also started removing parts of the harness and rerunning the eval corpus to see whether they actually matter.

One component dropped routing performance from 22/22 to 13/22 when removed.

Another produced no measurable difference in the current routing benchmark.

And I actually think the second result is just as useful.

Either the component isn’t helping, or the benchmark isn’t measuring what it is supposed to improve.

Both are things worth knowing.

The biggest current limitation is cross-host evidence.

The strongest real-use validation is still on Claude Code. Codex runtime packaging exists, but I don’t want to call it equivalent support until it has equivalent evidence.

What comes next: Continuum

I’m already working on the next-generation research architecture, Continuum.

A lot of its design is being inspired by ideas from physics, quantum theory, probability, information theory and decision science — not by trying to build a quantum computer, but by asking whether some of those scientific concepts can produce better execution systems.

For example:

superposition → preserve multiple plausible strategies
measurement → gather evidence before committing
contextuality → a capability’s value depends on the state around it
entanglement → coupled state across agents and modules
Value of Information → decide whether more information is worth acquiring
reversibility → govern exploration differently from irreversible action

The broader idea is to move from:

Task → Pick route → Execute

toward:

Intent → State → Alternatives → Observe → Update → Commit → Execute → Evidence

v1 stays independent and stable.

v1 is evidence, not baggage.

Continuum is where I’m testing what comes after it.

If anyone finds this area interesting and wants to contribute — whether through architecture, experiments, evaluations, agent memory, multi-agent systems, RLMs, context engineering or just trying to break the assumptions — I’d be very interested in collaborating.

A lot of the thinking behind this project has also come from researchers, open-source developers and AI creators who make their experiments and ideas public. That ecosystem has been incredibly useful.

I’m posting this mostly because I want criticism.

What feels over-engineered?

What would you remove?

What harness-level failure modes are you seeing that better models still don’t solve?

Repo:

https://github.com/SiddheshKGupta/Escapement

I wanted AI products to have a more recognizable “thinking” state than the usual spinner, so I built Benday.

It’s a free and open-source React component that animates your own logo while a response or process is running. It includes 21 presets, with controls for color, speed, dot shape, glow, and more.

Built with React, TypeScript, Tailwind CSS, shadcn, and Canvas.

Install it with:

bunx shadcn@latest add KacemMathlouthi/benday/benday

Then use it like this:

import { Benday } from "@/components/ui/benday";

<Benday
  src="/logo.svg"
  state={isThinking ? "thinking" : "done"}
/>

Demo: https://benday.kacemmathlouthi.dev
GitHub: https://github.com/KacemMathlouthi/benday

I’d especially appreciate feedback on the presets, API, and whether you’d use something like this in an AI product.

Looking for technical feedback on Aeris — a deterministic cognitive simulation engine

Hi everyone.

I've been working on an open source project called Aeris, and I'd really appreciate technical feedback from people interested in simulation, AI architecture, ECS, or cognitive systems.

Repository:
https://github.com/Cedrick-Coto/Aeris

I didn't start this project because I wanted to build "another AI."

I started it because I've always been fascinated by AI in video games, but most NPCs never felt truly alive. They usually react to scripted events, or now they rely heavily on LLMs for dialogue, but the world itself rarely feels like it has genuine internal consistency. The conversations may sound human, yet the characters often don't behave like coherent individuals.

That left me with a question:

If I wanted to build virtual characters that felt genuinely human, where would I even begin?

My conclusion was that I first needed to understand what makes us human.

So instead of designing prompts, I began studying my own way of thinking and trying to decompose it into systems that a machine could execute. Aeris became an attempt to translate that into an architecture rather than into a single AI model.

The goal isn't to prove that an LLM can think.

The goal is to build a cognitive simulation whose assumptions can be inspected, questioned, replaced and improved over time.

One of the main architectural decisions comes from that philosophy.

The simulation itself is deterministic. Every change in the world comes from systems such as perception, memory, affect, goals and reasoning. The language model never changes reality—it only verbalizes an already computed internal state.

That decision came after looking at several AI projects and Skyrim AI mods. While I liked how natural the dialogue could become, I often felt something was missing: the language sounded human, but the behavior behind it wasn't always grounded in a consistent world model.

I wanted to solve that at the architectural level instead of trying to patch it with better prompts.

That's also why the project uses an ECS architecture. I originally came from object-oriented programming, but after researching large-scale simulations and data-oriented design, ECS seemed like the right foundation for the kind of complexity I wanted to achieve. It forced me to learn a completely different way of thinking, but it also made the architecture much more scalable.

Another design choice is the extensive use of contracts and architecture documents. They're not there just for documentation—they exist so that months later I can still understand why a design decision was made, question it if necessary, and evolve the project without losing its reasoning.

Ultimately, my philosophy for Aeris is simple:

I want virtual worlds to feel alive.

I want characters to behave according to coherent internal processes instead of only producing convincing dialogue.

And I want the cognitive model itself to be replaceable as research advances. If future work provides a better explanation of human cognition, the engine should be able to adopt it without redesigning everything else.

At this stage, I'm not looking for praise.

I'm looking for criticism.

If you think the architecture is flawed, I'd like to know why.

If you see conceptual mistakes, that's even more valuable.

If you disagree with the cognitive model, I'd like to discuss it.

If you think some algorithms should be redesigned, I'd appreciate your perspective.

And if the project interests you enough to contribute code, review documentation, or simply follow its progress, I'd be grateful. Right now the project is still in an early stage, and building a community around thoughtful technical discussion would be one of the best outcomes I could hope for.

Thanks for taking the time to read this.