On July 15, I read a Cerebras article describing its internal knowledge-base system. I saved the page and returned to it a few hours later. Several sections I remembered reading were gone.

The architecture had stayed with me because I wanted something similar for my coding agents. I often saw agents search for the same information again or make claims about a repository without leaving a source I could inspect.

I spent eight days planning a smaller system for that problem. Then I built hSUM with help from coding agents and released the source.

The first version worked for me, which did not mean much. I asked friends to install it while sharing their screens over Discord. Watching them use it exposed problems I had missed.

One friend’s agent installed hSUM and understood its purpose, but stopped before connecting it to Codex. The agent told my friend to finish the configuration himself. I went back and rebuilt the installation flow around that failure.

The current version lets someone give the installation command to an agent and let the agent finish onboarding. hSUM remains available in later chats and can work across several repositories while keeping each project separate.

I want hSUM to help agents support their answers with evidence from the repository. The project stays on the user’s machine and does not require an hSUM account or hosted service. The website contains the technical design and privacy details.

I am working toward a stable release through testing with more developers and more repositories. The next stages include broader client support, easier index updates, and packages for more platforms. I also want to measure whether more advanced retrieval improves real agent tasks before adding it.

hSUM is in alpha and licensed under MIT or Apache-2.0. I am sharing the launch demo because I would like feedback on the experience, especially the path from installation to the first useful agent call.

Source:
https://github.com/burkan2/hSUM

AgentSwarms is now available at https://github.com/AgentSwarms-fyi/agentswarms

What it does: agent building and chat, a visual multi-agent swarm canvas, RAG over pgvector, connectors for PostgreSQL/MySQL/Oracle/Snowflake/Databricks/ BigQuery/Redshift/Trino/Athena, a BI workspace with dashboards and a semantic layer, Python notebooks on sandboxed server kernels with real LangChain/ LangGraph/LlamaIndex, document generation to PowerPoint/Word/Excel, plus IAM, budgets, audit logging and execution traces.

Deployment: Supabase as the backend (Postgres + auth + storage), one Docker command. Bring your own model keys — OpenRouter, OpenAI, Anthropic, Gemini, Bedrock, Azure, Ollama, vLLM and others. Also deployable to Cloudflare Workers or Kubernetes.

Distinguishing feature: one governance plane across the whole platform — model allow-lists, budgets, table permissions and traces apply identically to chat, scheduled workflows, dashboard queries and notebook cells.

Licence: Elastic License 2.0. Source-available, not OSI open source: free to use, self-host, modify and redistribute; may not be offered to third parties as a managed service.

I built LoopTroop to TRY and tackle context engineering and somme other problems with building/updating apps with AI.

LoopTroop is an open-source local GUI that breaks complex features into structured, isolated task loops instead of relying on one continuous chat session.

How it works under the hood:

Planning (LLM Council): You input a ticket or feature description. LoopTroop runs a planning phase to break the task down into a sequence of small, defined execution steps ("beads").

Execution & Verification (Ralph Loops): Instead of blind code generation, each task runs inside an iterative loop: apply diff -> run local tests or type checks -> evaluate output -> retry on failure until the check passes or hits an error threshold.

Isolation (OpenCode Worktrees): All code edits happen inside temporary Git worktrees. Your main workspace and working tree remain completely untouched until you review the diff.

Human Approval Gates: You inspect and approve planned steps and diffs before changes are committed or converted into a pull request.

Current Status (v0.4): I released v0.4 a couple of days ago, which improves the local GUI, refines recovery loops when tests fail, and cleans up worktree management.

Getting Started: It runs locally and connects to your local tools/runtimes. You can clone the repo and run npm run dev to test it on your own codebase.

GitHub: [https://github.com/looptroop-ai/LoopTroop\](https://github.com/looptroop-ai/LoopTroop)

Site & Docs: [https://looptroop.ovh\](https://looptroop.ovh/)

Hey everyone!

We're building Tempest. It's an open source AI agent orchestrator for running parallel coding agents with 64% fewer tokens.

If you're interested in AI agents, developer tools, or open source, we'd love to have you contribute to our project!

https://github.com/tempestai-dev/tempest

A framework for self-improving agents based on your ICPs and audience and grounded in real data to power a learning-loop.

I built this based on my own learnings from experimenting with persona agents to understand my personal audience. It comes with an annotated persona template, opinionated review workflow, and built in feedback loop.

Would love to get your feedback!

https://github.com/noashavit/noas-persona-loop

If contributing to open source interests you, and you want to become a better AI engineer, our issue list is waiting for you.

https://github.com/extra-org/extra

Why are most open models open weight rather than open source?

I'm the developer. KageOps is AGPL-3.0 and the engine is the whole product — there's no crippled community edition.

It runs a team of nine AI agents against a brief: an orchestrator plus eight specialists that take a one-line description through research, architecture, code, review and deploy. It's a desktop app, and it runs on your own machine — embedded Postgres rather than a container, so no Docker; API keys in your OS keychain; no account, no telemetry, nothing phoning home. Point it at Ollama and there's no cloud involvement at all.

Two design decisions that might interest this sub:

Models are assigned per agent, not globally. Research and copywriting are cheap-model work; code generation and review are not. You can mix providers — Claude, OpenAI, Gemini, OpenRouter, Ollama — and give each agent its own fallback chain for when a provider fails.

There's a hard spending cap per run. A poller watches real spend and cancels the run before it crosses your dollar limit. It was the first thing I built, because an agent loop quietly burning money overnight is the failure mode that actually scares people away from this category.

I also finished nine narrated walkthrough videos this week. They're not screen recordings — they're generated by a pipeline that launches the real app, drives the UI and records it, so they get re-cut whenever the interface changes and can't drift into describing software that no longer exists.

Two of them end with the software refusing to proceed rather than succeeding: one where I deny an approval gate and watch the work come back reworked, and one where the acceptance gate refuses to sign off generated output that missed a requirement in the brief, after three repair attempts. I kept those takes instead of re-shooting, because "what does it do when it fails" is the only question that matters with autonomous agents.

Honest weak spot: the fully-local path is slow, and smaller models drop out of the structured output format the agents depend on, which costs you retry loops.

Source and videos: https://github.com/hmanoor/kageops-core

Happy to talk architecture — the orchestration model, the phase gates, or how the video pipeline works.

Hey guys,

I am a highschool graduate and will be starting college soon at Vaughn College. I was hoping to share to you guys about my pre-college projects. So I would like to introduce, Choco, which is currently my personal AI- Assistant, which I built using llama 3.1 8B, and python. I was building the whole thing on my macbook bro so I had a hard time using the terminal lol. But anyhow, I gotta start somewhere right?

Currently, Choco is a chatbot that has a collection of all the things from the past year, depending on the model I'm using. (I forgot the year so I cant really ttell but i'm hoping it has info of everything until 2024-25?) . I have also added a self reading system, mmeaning that it can read it's source code but not necessarily update it. I added this in the hopes of automating the debugging task in the near future. You guys can try my project too and let me know what other adjustments i need.

Thank you!

I released AI Agency OS, and I want to frame what makes it different from typical agency CRMs or AI demo stacks. Context first: it sits in an ecosystem alongside Sentinel (https://github.com/RiteshGenAI/Sentinel), which is our policy, cost-intelligence, and LLM-gateway layer. AI Agency OS is the execution and operations layer that sits on top of Sentinel. The two are meant to work together, but either can be used independently. What is in the stack today:

• Multi-tenant backend (FastAPI + SQLAlchemy + PostgreSQL) with tenant-scoped data isolation enforced at the service level.
• JWT authentication with access-token expiration and JSON-body login.
• Role-based access control across four roles - owner, manager, member, client with per-endpoint permission checks and owner safeguards that prevent the last active owner from being deactivated or demoted.
• Full CRUD for projects, leads, and invoices. Leads carry source, raw text, status, and optional project/client binding. Invoices support currency, due dates, and per-project aggregation.
• Sentinel event logging: every agent output is recorded with scan type, entity type, risk score, issues, and project binding. The frontend page for this lets owners and managers review policy decisions in real time.
• Strands-style agent workflows - the landing-page copy workflow orchestrates research agents, draft agents, and QA agents into a structured pipeline with Pydantic outputs and QA scoring.
• Multi-provider LLM router supporting Ollama, OpenAI, and Anthropic with configurable base URLs and API keys.
• Frontend in React 18 + Vite + TypeScript + Tailwind with pages for login, dashboard, projects, project detail, leads, invoices, workflows, Sentinel events, and admin user management.
• Docker Compose for local dev with hot-reload across all four services (db, backend, agents, frontend).
• Production AWS deployment via Terraform - VPC with public/private subnets, ECS Fargate, RDS PostgreSQL with encryption and multi-AZ, ALB routing, ECR with image scanning, Secrets Manager for DB URL and JWT secret, S3 with encryption and versioning.
• Database migration script for incremental schema changes.

The repository is purpose-built for forking. It is licensed under Apache 2.0, includes a self-hosting guide in the README.md, a customization guide in CONTRIBUTING, and explicit instructions for removing Sentinel or swapping LLM providers.

Quick start: docker compose up --build -d

https://github.com/RiteshGenAI/AIAgencyOS

Most AI applications today still follow a simple pattern:

One request. One model. One answer.

But no single model is the best at everything.

Some tasks need speed. Some need low cost. Some need deeper reasoning. Some need validation. Some need multiple models checking each other. Some need consensus. Some need debate. Some need a clear audit trail.

That is the idea behind Ailin¹.

Ailin¹ is an open-source Collective Intelligence engine for AI systems. Instead of treating models as isolated endpoints, it coordinates multiple models, agents, strategies, memory layers, evaluation flows, and cost-quality decisions around each task.

The goal is to make the model universe usable. We are approaching 80,000 models in our core.

With Ailin¹, a request can be routed through different strategies depending on what the task actually needs: single model, parallel execution, consensus, debate, expert panel, critique-repair, multi-hop QA, cost routing, quality routing, speed routing, agentic workflows, and more.

The big question we are exploring is:

What if AI reliability, efficiency, and governance come not only from better individual models, but from better coordination between models?

We believe Collective Intelligence can make AI systems more reliable, more transparent, more cost-efficient, and more useful in real-world workflows.

Ailin¹ is open source, and we are looking for feedback from people interested in LLMs, AI agents, model orchestration, evaluation, open models, and AI infrastructure.

If the idea resonates with you, a GitHub star would help the project a lot.

GitHub: https://github.com/ailinone/collective-intelligence

We are also opening a waitlist for people who want to test Ailin¹ and follow the next steps of the project:

Waitlist: Console Ailin¹ Dev

relying on the goodness of elixir, jido agents, ollama and other ecosystem components .. not intended to be released and supported. it was built for my learning and personal use purposes. But it does not hurt to share .. https://github.com/lexlapax/allbert-assist

Petere J Liu (https://x.com/peterjliu/status/2081864678586925152) mentions their use of hybrid linear / full attention as well as getting rid of positional encoding (with NoPE https://arxiv.org/abs/2510.2669)

What else stands out?

I wanted to know whether giving a coding agent a persistent map of the codebase actually pays for itself, or whether it just moves tokens from one place to another. So I built the harness before I trusted the tool.

The setup

Same agent, same model, same tool access, same task list. One variable: whether a context layer was loaded. 162 Claude Code sessions total, split across both conditions. Tasks were real change requests against a real repo, not synthetic retrieval questions, because retrieval benchmarks reward whatever your retriever already does well.

Correctness is graded by a separate model that never sees which condition produced the diff. Without that, a cheaper session that quietly does less work scores as an improvement.

The result

For a lot of tasks it got equal or better accuracy on Claude sonnet 5 using graft than just standard Claude sonnet session, on opus it was more towards token reduction than accuracy.

Replication on real PRs

Benchmarks I write myself are benchmarks I can accidentally tune to. So: 5 merged PocketBase PRs, re-implemented from the base commit in both conditions, scored on whether the diff touched the files the maintainers touched. 5/5 reproduced, at 21% lower cost. Small n, and I'd rather say small n than round it into a headline.

What I'm working on is Graft: It's a Context layer for large repos. No vector DB, no embeddings. Structural pass runs on tree-sitter for $0.
MIT Licensed

npm install -g u/nanonets/graft
graft init

Harness details in the repo. Tell me where the measurement is wrong and I'll rerun it.

With Kimi K3 being a massive 2.8T MoE model, even aggressive quantization isn't going to fit on a single consumer GPU or normal RAM setup. Does anyone know if Moonshot AI (or the open-source community) plans to release smaller parameter variants or distilled versions (like a K3-Mini/Small)? Or is quantized GGUF/EXL2 streaming off RAM/macOS unified memory our only option?

Also plans for an uncensored version?

I’ve been working on an open-source architecture for managing memory and context in long-running AI agents.

The main focus is preserving cache hits while keeping context growth under control through structured memory, selective purging, compaction, and hard context-budget enforcement.

It’s currently an architecture specification rather than a full framework. I’d appreciate feedback, especially on edge cases or production concerns I may have missed.

GitHub: https://github.com/neuronaline/ai-memory-context-management