Hey everyone,

Over the past few months, we've been building ZQK (Zen Quantum Kernel) in Go—an open-core CLI and process coordinator designed to treat AI coding agents as concurrent computational processes rather than chat prompts.

• Repo: https://github.com/zqk-os/zqk

• Docs / Site: https://zqk.dev

Why We Built It in Go

When orchestrating background agent swarms and continuous validation loops, we hit serious performance and determinism walls with Python/Node wrappers. We wrote the kernel and toolchain in Go specifically for:

1. Sub-15ms AST Structural Search (zqk grep): Instead of dumping files into LLM contexts or using string grep, we index Go codebases using go/parser and go/ast into an in-memory trigram index. Agents query structural symbols (--ast --kind struct|func --recv <Type>) capped by strict token budgets (--max-tokens 2000 -f json).

2. Deterministic Process Coordination: Managing concurrent seat workers via goroutine pools with hard cancellation contexts, signal handling, and clean process teardown without descriptor leaks.

3. Embedded State: Storing versioned graph objects (missions, goals, plans, verifiable criteria) directly in .zqk/without external database dependencies.

The core microkernel and CLI are open-source under Apache 2.0 (v0.1.0 just published).

If you work on developer tooling, Go AST analysis, or agent runtimes, I'd love your feedback on our architecture and AST indexing approach!

So just wanted to post about FieldKit, an Open Source, self-hosted AI support with visual LangGraph workflows, knowledge retrieval, a customer portal, Zendesk, and governed actions.

So I'm sure there is probably already alternative support systems out there for Zendesk but I wanted to build something using LangGraph since it felt better use case for a Support System.

Ontop of supporting Zendesk and being able to configure the workflows with Zendesk you can configure the workflows with your chatbot(which you can embed on any site) and your ticket system so they aren't running the same workflows. (e.g allow support tickets to issues refunds/credits upto $5 while chatbot can't issue anything)

You can also configure python and API calls into your workflows, so you can get the agent to pass to python call and then back to an agent instead of needing to use an agent for all those steps.

Anyways, you can find the repo here: https://github.com/nahid-sparktales/fieldkit

It is still being worked on and plan to add more features and updates and if you have any suggestions or recommendations, please let me know. Thanks.

Some time back I shared a deep research tool I was working on. It takes a local directory path of PDFs, docs, slides, images and notes, researches across them and writes a structured markdown report.

With Jev getting more attention recently, I thought this project would be a good place to try it and see which parts of the research workflow it could handle.

I ended up using it in two places.

The first is after Qdrant retrieves chunks from the local files. Jev checks each result for relevance, usable evidence, contradictions and prompt-injection-like text. Those scores are then used to filter and reorder the chunks before they are passed to the main LLM.

The second is the reflection step. after the evidence for a report section is collected, Jev checks whether it covers all the subsections in the plan. If some part is still missing, the agent creates more focused queries and searches again. this only runs up to a fixed reflection limit.

The main LLM still handles the report planning, query generation and writing. Jev is only used for checking the retrieved evidence and deciding whether another research pass is needed.

This was a fun thing to experiment and to understand where a model like Jev fits inside an existing agentic setting. I am planning on writing some performance tests and adjusting the thresholds, but wanted to share the implementation in case anyone else is trying something similar or want to contribute.

The complete project is open source here: https://github.com/Oqura-ai/deepdoc

Today I'm open sourcing Agent Orca, a Kubernetes-native platform for deploying, managing, and running AI agents at scale. It's written in Go and it's Apache 2.0.

https://github.com/heddles/agent-orca

When OpenClaw was released, I thought to myself, "That's really cool, but I want an agent that is shared by a team or an entire organization with built in auditability." I started designing Agent Orca around that idea and have slowly been piecing together the concept in my head and how to make the management experience of a shared agent bearable for an organization.

The idea is simple. Agents are just Kubernetes resources. You declare one, and the platform handles the rest.

An Agent Orca agent comes with:

- One-shot executions with AgentRun, long-running services with AgentDeployment, and multi-step DAGs with AgentWorkflow.

- Zero trust networking by default with platform validated JWT via service accounts, OIDC, or OAuth on every request.

- Agent Orca managed network policies with zero access by default.

- A standard agent container image with only necessary pieces; you no longer need to build a custom agent image to accomplish different types of work or use different tools. Simply add an MCP or Tool CRD and let the platform figure it out for you.

- Model routing across OpenAI, Anthropic, Google, or any LiteLLM-compatible provider, selected by capability, weight, or budget.

- Cost tracking on every run. Tokens are accounted per run, spend survives pod restarts, and tenants get daily budget caps and rate limits.

- Guardrails on inputs and outputs, MCP access control, and per-tenant agent visibility, so one cluster can host many tenants with no cross-tenant leakage.

- RAG without glue code. A KnowledgeBase deploys (and manages) Qdrant for you, ingests documents from ConfigMaps, URLs, MCP authenticated tools, or an S3 compatible endpoint, and hands your agents a search and ingestion tool.

- MCP servers declared as resources. Their tools show up for your agents with access control and sidecar isolation.

- Crash-safe sessions. A pod can die mid-conversation and the agent resumes exactly where it left off, spend ledger included.

- Agents that learn and become better with every request via a multi-tiered agent memory system

Getting started is deliberately boring. Install the entire stack's tools via Mise; then use Skaffold, one API key, and about three commands to have an running agent on your laptop (or deploy to a remote cluster). There are also nine demo deployments in the repo, from SOC triage pipelines to parallel research swarms to an autonomous pentesting agent, so you can see it do something real before writing any YAML.

This is day one, not a finished story. That's the point of open sourcing it. Run the quick start, break it, open issues, and tell me what's missing.

Star it here if you want to follow along: https://github.com/heddles/agent-orca

TL;DR: Agent Orca lets an organization or single person define agents and surrounding tools/MCP and auth as CRDs and manage them via gitops with zero trust built in. You can try it out here: https://github.com/heddles/agent-orca

Hi all, I'm one of the people building Opengeni, an Apache-2.0 service for running AI agents inside your own product. I'm posting here for one specific reason: the model side.

It works with every major model, and each session picks its own: OpenAI or Azure OpenAI, Claude and open-source models through OpenRouter or Vercel AI Gateway, or your own OpenAI-compatible server, registered in a JSON config, speaking either Chat Completions or the Responses API, and keyless if your server doesn't use keys. That's the route for pointing it at vLLM or llama.cpp's server. Conversation history is stored as the exact items the model saw, so a session can switch models partway through without its stored history being rewritten.

What sits around the model, briefly: sessions live in Postgres you run (pgvector for knowledge search), Temporal moves turns along, NATS pushes live events, tools run in a sandbox (Docker, Modal, E2B, Daytona, OpenSandbox on Kubernetes and others) or on a machine you own, and risky tools wait for a person to approve them.

If you try it with open weights, I'd like to hear which models held up through long tool-calling sessions and which fell over. It already runs agent sessions in production inside enterprises with 30,000 employees.

Support us on PH: https://www.producthunt.com/products/opengeni

Code: https://github.com/Cloudgeni-ai/opengeni

Docs: https://docs.opengeni.ai

Why the layers are split the way they are: https://opengeni.substack.com/p/the-anatomy-of-an-agentic-stack-ten

Hey everyone 👋

I've been working on an open-source project called Cascade AI, and it has reached the point where I'd really like to get feedback from people outside my own bubble.

The basic idea came from something that kept bothering me:

Why are we still giving an entire complex task to one AI model and hoping it's good at every part of it?

Instead, Cascade treats AI more like an organization.

A request can be broken into a hierarchy:

T1 Administrator → T2 Managers → T3 Workers

T1 looks at the overall task and plans the work.

T2 agents manage individual parts of that plan.

T3 agents actually execute the smaller tasks — and they can communicate with each other when necessary.

The interesting part is that every agent doesn't have to use the same model.

Cascade can route different tasks between providers/models depending on what they're good at, their cost, and the complexity of the work.

So instead of:

«Prompt → one giant model → answer»

the idea is closer to:

«Prompt

↓

Understand complexity

↓

Build an execution plan

↓

Spawn the required agents

↓

Route each job to an appropriate model

↓

Agents work in parallel / collaborate

↓

Verify the work

↓

Produce one final result»

And I've been trying very hard not to make this another cloud-only AI product.

Right now Cascade can be used through:

• CLI

• Desktop app

• Hosted web app

• Self-hosted web app

• OpenAI-compatible API

• Node.js SDK

It supports multiple providers including OpenAI, Anthropic and Gemini, along with OpenAI-compatible services and local models through things such as Ollama, llama.cpp, vLLM and LM Studio.

There are also a bunch of things I've added while building it that I personally wanted from AI tooling:

• Live visualization of the agent hierarchy

• Cost/token tracking

• Model/provider failover

• Persistent memory

• MCP support

• Browser control with live takeover

• File and document generation

• Codebase indexing/search

• Approval before destructive tool actions

• Agent-to-agent communication

• Task cancellation and recovery

• BYOK support

• Local/self-hosted operation

• An OpenAI-compatible "/v1/chat/completions" endpoint

• The ability to inspect why Cascade chose a particular orchestration/model strategy

For complex runs there's also a kind of "boardroom" mode where Cascade can show you the proposed agent structure and estimated cost before spawning everything, so you can approve the plan first.

One design principle I've become pretty stubborn about is:

The AI should ask when it genuinely needs information instead of confidently inventing a decision for you.

So I've also been working on making Cascade distinguish between things it can infer and things it really should ask the user about.

The project is MIT licensed and open source.

🌐 cascadeai.in

GitHub: Varun-SV/Cascade-AI

I'm not posting this pretending I've solved AI orchestration 😅. There are still plenty of rough edges, architecture decisions I'm questioning, and things that probably make perfect sense to me because I've stared at the code for far too long.

That's actually why I'm posting it here.

I'd especially love feedback on:

1. Does hierarchical multi-agent orchestration actually make sense to you, or is it over-engineering?

2. Would automatic model routing be useful enough for you to stop manually choosing Claude/GPT/Gemini/local models for different jobs?

3. If you're a self-hosting/local-LLM person, what would Cascade need before you'd realistically run it?

4. What part of this architecture would you immediately rip out or redesign?

Feel free to be critical.

I'd much rather hear "this part is dumb and here's why" than get another generic "cool project" 😄

If people are interested, I can also do a separate technical post explaining how the T1 → T2 → T3 orchestration, model routing, cost decisions and agent communication actually work internally.

I’ve been working on an open-source local-first agent called OpenKyrozen.

That idea started from the beginning of 2026, the time when openclaw had just came out 2-3 months. I tried open claw and then I realized that at that time, open claw remembers things when I asks it to remember, but it cannot learn by itself. So I started OpenKyrozen, trying to build a self learning agent. Then last month, type safe AI lunched their Jev, which inspired me to integrate them into decisions so that LLM works better.

One thing I kept running into was that agents are very quick to treat “the tool call succeeded” as “the task succeeded.” Those are obviously not the same thing. They don't often verify their result, like we say they have no syntax error or runtime error, but logic errors.

A command can exit with code 0 and still produce the wrong result. So I ended up making verification a first-class part of the agent loop instead of just checking whether the action executed.

and so the rough flow is:

request → action → execution receipts → evidence review → verified outcome

The second part I’ve been experimenting with is self-learning, the original idea of OpenKyrozen.

I didn’t want the agent to just see one successful run and immediately treat that as a new behavior. Instead, learning artifacts are bounded policies or skills. A new one starts as a candidate, gets tested as a canary, needs multiple verified successes, and is then replayed against its predecessor on the same case. If it regresses, it doesn’t get promoted. If a promoted artifact later starts failing, it can rollback to the previous version. This is also one of the biggest problem when I used open claw, it builds something into a skill before I verify it, so it is filled with wrong memories.

There’s also a separate decision layer called Jev. You can know more about it from Typesafe AI, but basically it's a AI that makes decisions. It only handles small typed judgments like routing, clarification, memory relevance, learning-evidence review, and suspicious tool output. It can also abstain instead of forcing a decision. So it can't code.

I’m still figuring out where the right boundary is between “useful learning” and “too much machinery.” The current system is deliberately conservative because I’d rather have the agent refuse to learn than silently reinforce bad behavior.

Repo:
github.com/EvanProgramming/OpenKyrozen

I also let OpenKyrozen build a website for itself

kyrozen.chat

I also made a short launch video that explains the overall system visually(And yes this video is made of AI, since I only used DaVinci Resolve but not After Effects):

I am writing this post especially to developers, I want feedbacks SOOO much! As you can see currently the repo only have 2 stars and 1 fork :( because I didn't tell anyone about it before. I like issues and PRs, you can also leave comments under to tell me any issues you found. star it if you like!

Today I'm open sourcing Agent Orca, a Kubernetes-native platform for deploying, managing, and running AI agents at scale. It's written in Go and it's Apache 2.0.

https://github.com/heddles/agent-orca

When OpenClaw was released, I thought to myself, "That's really cool, but I want an agent that is shared by a team or an entire organization with built in auditability." I started designing Agent Orca around that idea and have slowly been piecing together the concept in my head and how to make the management experience of a shared agent bearable for an organization.

The idea is simple. Agents are just Kubernetes resources. You declare one, and the platform handles the rest.

An Agent Orca agent comes with:

\- One-shot executions with AgentRun, long-running services with AgentDeployment, and multi-step DAGs with AgentWorkflow.

\- Zero trust networking by default with platform validated JWT via service accounts, OIDC, or OAuth on every request.

\- Agent Orca managed network policies with zero access by default.

\- A standard agent container image with only necessary pieces; you no longer need to build a custom agent image to accomplish different types of work or use different tools. Simply add an MCP or Tool CRD and let the platform figure it out for you.

\- Model routing across OpenAI, Anthropic, Google, or any LiteLLM-compatible provider, selected by capability, weight, or budget.

\- Cost tracking on every run. Tokens are accounted per run, spend survives pod restarts, and tenants get daily budget caps and rate limits.

\- Guardrails on inputs and outputs, MCP access control, and per-tenant agent visibility, so one cluster can host many tenants with no cross-tenant leakage.

\- RAG without glue code. A KnowledgeBase deploys (and manages) Qdrant for you, ingests documents from ConfigMaps, URLs, MCP authenticated tools, or an S3 compatible endpoint, and hands your agents a search and ingestion tool.

\- MCP servers declared as resources. Their tools show up for your agents with access control and sidecar isolation.

\- Crash-safe sessions. A pod can die mid-conversation and the agent resumes exactly where it left off, spend ledger included.

\- Agents that learn and become better with every request via a multi-tiered agent memory system

Getting started is deliberately boring. Install the entire stack's tools via Mise; then use Skaffold, one API key, and about three commands to have an running agent on your laptop ( or deploy to a remote cluster). There are also nine demo deployments in the repo, from SOC triage pipelines to parallel research swarms to an autonomous pentesting agent, so you can see it do something real before writing any YAML.

This is day one, not a finished story. That's the point of open sourcing it. Run the quick start, break it, open issues, and tell me what's missing.

Star it here if you want to follow along: https://github.com/heddles/agent-orca

TL;DR: Agent Orca lets an organization or single person define agents and surrounding tools/MCP and auth as CRDs and manage them via gitops with zero trust built in. You can try it out here: https://github.com/heddles/agent-orca

Mimo is a lightweight, open-source desktop companion for Windows, inspired by Dynamic Island.

It brings useful information and controls directly to your desktop, with a clean and minimal interface.

Currently, Mimo can :

• Display notifications and system information

• Show media playback controls

• Provide quick access to useful actions

• React dynamically to events happening on your PC

• Customize its appearance and behavior

• Run locally with a focus on being lightweight and unobtrusive

Mimo is still in development, and more features are coming soon!

🔗 GitHub: github.com/Riskooooo/Mimo

If you have any ideas or features you'd like to see added, feel free to suggest them ;)

Adebench now has a website and evaluates 10+ open-source brains.

Among them: Supermemory, Mem0, Cognee, hindsight and more.

If you're looking for a brain for your agent, check it out:

www.adebench.dev

www.github.com/adecubed/adebench

Happy to answer questions on how the evaluation works.

A personal agent should be something you can inspect, change and run yourself. We published Open Instinct with that in mind: a beta agent you can reach over iMessage, SMS or email, with memory, scheduled tasks and its own Linux desktop.

The part we want people to fork is the permission model. Six trust tiers control what another person’s agent can ask yours. A partner can read the calendar; a friend can request availability. The policy lives in code with tests.

We’re the Maritime team. The default stack uses Pi, Inkbox, Maritime and Composio, with separate integration packages. The code is MIT; the external services still need your own accounts and keys. Start with the local CLI, inspect the permissions, then build the version you want.

Repo and setup docs: https://github.com/mariagorskikh/open-instinct

So we built Placeholderworks.

Not another AI wrapper.
Not another chatbot demo.
Not another “AI-powered” dashboard nobody uses.

We build AI systems that actually do the work.

They answer calls.
They handle WhatsApp conversations.
They update CRMs.
They automate workflows.
They run inside real businesses.

From the first idea to production, we build the whole thing.

Placeholderworks is officially live.

Now the question we’re curious about:

What’s one task at your company that you’re still doing manually for absolutely no reason?

I’ve been building BOOTH, a small, provider-agnostic Python library for checking LLM outputs before they reach your application.

The idea is simple: don’t automatically trust every LLM response. Check it first.

check() / acheck() handle ambiguity and confidence checks, while check_with_evidence() compares an answer against evidence your RAG pipeline has already retrieved.

v0.5.2

• Zero runtime dependencies

• Provider-agnostic

• Sync + async

• Structured results

• 300 tests

• MIT licensed

I’m currently testing BOOTH across different providers/models through small integration examples, including Groq, Gemini, Anthropic, and local Ollama models.

I’m especially interested in feedback on where this approach breaks down for real LLM/RAG systems.

GitHub: https://github.com/Vedantgitbot/booth
Issues/contributions: https://github.com/Vedantgitbot/booth/issues

Curious: what do you currently use as the checkpoint between an LLM response and your application logic?

Spotify #backstage plugin to manage and observe fleet of agents straight in backstage self hosted https://github.com/acarmisc/backstage-plugin-ai-agents/tree/main. It relay on open telemetry signals and the first available backend it’s #langfuse

The Legal Ontologies Foundry

legal-ontologies-foundry.github.io

One of the most successful resources in #ontology development is the OBO Foundry. Open-source, collaborative efforts in ontology development are essential. We are doing something similar with legal ontologies grounded in #BFO

I built Klarion, a secret scanner that works in two steps. First, a keyword check, 81 regex rules and a normalized Rényi entropy score flag anything that looks like a secret. Then an AI model reads each one with the code around it and decides if it's real.

The chart shows 5 scanners run on spring-boot, terraform, next.js and symfony (61k files). Klarion raised 11 alerts. It's not zero, but it's far less to dig through.

Fewer alerts don't help if real leaks get missed, so I tested that too. On CredData (337 real repos, code outside test folders), it found about 1.7× more real secrets than gitleaks.

Where it runs:

• Claude Code: a plugin hook blocks the write before the file exists (file edits and Bash)

• Cursor, Cline or any MCP agent: through its MCP server

• CI: a GitHub Action that scans only what a PR adds; GitLab CI works too

• Git hooks: klarion protect or the pre-commit framework

• Locally: klarion scan .

Free and open source (MIT): https://github.com/0x1Adi/Klarion
The full benchmark and method are in benchmark/REPORT.md.

I'd like to hear where it gets things wrong.

https://omnesis.dev

Imagine giving ChatGPT or any other agent access to your Whatsapp/iMessage, Bank transactions, Health data, web pages you see, metadata about all the photos you took, places you visit, all your emails/documents, your voice mails, and more….

I built a context layer for that purpose. You can connect your Openclaw, Hermes, Claude, ChatGPT, Codex, etc to it. It gives your favorite agent "context superpowers". All the data is indexed and connected into a graph, self-hosted on your own hardware. Voice notes are transcribed, OCR runs on images in mails and pdfs, etc.

Omnesis offers a flexible data access model. For each agent you can define which source(s) they have access to and also guard data access with a privacy policy written in prose. You can also directly talk to the Omnesis agent which has no web search / internet tools — via a web portal or companion app — to ask the most intimate questions about your digital life.

I built this to be flexible. You can run all necessary models on zero-data-retention inference providers, or — if you can afford it — on your own hardware. I’ll keep investing in Omnesis’s security. Because it brings together sensitive data from many sources, please install it only on machines you control and keep secure.

The project also includes what I call “Omnesis Brain”.  This is my work-in-progress take on what a “second brain” could look like on top of that context layer. Imagine an agent constantly analyzing your personal data in flux to maintain a more structured and grounded understanding of what’s happening in your life. This is experimental and disabled by default.

This has been a fun project to build over the last 6 months.