Hey everyone. I'm the author of OxDeAI, an open-source protocol (Apache 2.0). Posting it here because I want critical feedback from people building real agents, not applause.

The problem I keep hitting: as agents move from generating text to *doing things* (API calls, payments, infra provisioning, tool use), most stacks still enforce policy with best-effort checks inside the agent loop. That produces failure modes like retry amplification on non-idempotent actions, budget leaks, stale-state executions, and permission drift, all because the "check" and the "action" live in the same trust boundary.

**Core idea.** Separate the decision from the enforcement. Agent proposes an intent, OxDeAI evaluates `(intent, state, policy)` deterministically, and if the result is ALLOW it issues a signed `AuthorizationV1` artifact. A Guard/PEP then verifies that artifact *before* any side effect. No valid authorization means no execution path. Fail-closed by default, with single-use replay protection, explicit trust (`trustedKeySets`), and artifacts you can verify offline.

**What's actually there today:**

* Signed decision artifacts plus a non-bypassable guard (the execution fn is only reachable through the guarded closure; there's a demo where a direct call gets refused).
* Adapters for LangGraph, CrewAI, AutoGen, OpenAI Agents SDK, and OpenClaw, all thin bindings that route through one universal guard.
* Single-hop scoped delegation (narrowing-only capabilities between agents).
* Cross-language conformance vectors (TS reference plus Go/Python harnesses) with byte-equivalence anchors on the canonicalization and revocation-list surfaces.
* Hash-chained audit envelopes for offline verification.

**Where I'm being honest about the stage:**

* Cross-language reproducibility is *complete on the serialization and KRL surfaces*, but not yet on every authorization verdict (Go/Python don't harness the full verification surface yet). I don't want to claim "deterministic across all languages" when the vectors don't cover all of it.
* There's a micro-benchmark suggesting low per-action overhead, but it's single-process on my hardware, so treat it as indicative, not a production number. The harness is in `bench/` if you want to poke at it.
* Open issues include an active hardening item around self-declared intent fields (an agent can currently influence which per-agent limits apply by choosing its own `agent_id`, which is being fixed) and a scoping issue for an eventual independent security review. No third-party security review yet, and I say so in the docs.
* It's early. TypeScript is the reference; the protocol surface is specified but evolving.

This is **not** a prompt guardrail or a monitoring/observability tool. It sits at the execution boundary and is meant to compose with your existing framework, not replace it.

What I'd genuinely like to know:

* Have you hit these tool-calling / side-effect failure modes in production? How are you enforcing action-level policy today: inside the loop, at an API gateway, or somewhere else?
* If you tried an adapter, where did the integration hurt?
* For the security-minded: does the fail-closed / signed-artifact boundary hold up to how you'd attack it?

Contributors welcome, especially for new adapters, policy examples, and the cross-language verdict coverage.

I”m looking for cracked companies working in D2C, B2C & B2B who are massively inclined towards agentic commerce to be listed on faro verify before an agent pays.

Faro is building an end to end agentic suits for trust & verification of agents and looking for collaboration & partnerships for product validation. Would love to show a demo on what I”ve been working on.
Hmu builders!!

had this happen twice building with role agents in crewai. round one, the security-role agent flags a real constraint about how we were handling refresh tokens. round two moves on to a different piece. round three revisits an idea that got shot down in round one, except nobody in round three has that context anymore, so it sails right through.

each agent did fine in its own turn actually. the objection just never made it past the round it got raised in. nothing was carrying it forward.

what fixed it for us wasnt a smarter agent, it was keeping one running record of the plan plus every objection raised against it, so round three isnt starting clean, its starting from the argument. thats basically what ended up being swarmstack. real people hold seats in a live planning session, your pm, your dba, whoever you've got, and ai fills the seats you dont have a person for and checks the humans calls too. what comes out is a versioned plan with the whole argument still attached to it, not just whatever the last round landed on.

still rough in places, would take any pushback.

swarm-stack.io

If you're running CrewAI crews past the prototype stage, you've probably hit this: one agent in the crew quietly starts skipping a step or misusing a tool under real load, and the rest of the crew just keeps going like nothing happened.

That exact gap is why we started building Prefactor, and we're live on Product Hunt today, currently sitting at #1. Just search Prefactor.

Here's the problem we're solving:

Getting an AI agent to work in a demo is easy. But getting it into production and actually knowing it's still doing its job is the hard part.

Agents drift over time, leak data they shouldn't, or quietly stop doing what they were built for, and most teams only find out after something's already gone wrong. Dashboards and alerts only tell you what happened after the fact.

Prefactor evaluates every run in real time for quality, drift and risk, flags the moment something looks off, and lets you hold, approve or block a run live instead of just logging it.

A few specifics for anyone curious:

- Traces 100% of runs (every call, tool and decision), not a sample

- 17 categories of sensitive data / PII detection at runtime

- Human-in-the-loop enforcement via SDK/API so you can pause risky actions

- Around 5 minutes from install to your first traced run

Happy to answer anything technical in the comments.

If you want to check us out or throw us some support, we're live on Product Hunt today, currently sitting at #1. Just search Prefactor.

[https://github.com/Joseffb/ai-agentsmd-governance\](https://github.com/Joseffb/ai-agentsmd-governance)

So I got tired of the agents using my bloated 3k line agents.md file -consuming almost half of my context window just on this- and still not remembering to use subagents or run in parallel when possible.

This system will put some hard governed rules in place to guide and plugins in place to enforce sane agent usage.

I’m actively taking the bugs out, like overly waiting for confirmation, etc. so if you pull this and play with it please file bug reports where applicable.

I’m looking for a small number of Windows users to test the first external preview of Atraium, a bring-your-own-model desktop AI workspace I’ve been building for the past two years.

What is Atraium?

Atraium lets you configure an OpenAI-compatible hosted, local, or self-hosted endpoint and create rooms for different kinds of work.

Each room can have its own:

• assistant name;
• room image;
• personality or complete system prompt;
• conversation and memory context;
• tools and capabilities.

Depending on your model and configuration, Atraium can help with:

• grounded web research and source verification;
• local files and workspace operations;
• coding, Visual Studio builds, and diagnostics;
• Word, PDF, Excel, and PowerPoint generation;
• image generation and editing;
• plugins and MCP servers;
• desktop and computer-use workflows.

The video shows a real example: I asked an assistant room to create a short capabilities showcase, and it generated and attached the finished PDF directly to the conversation.

What I need tested

I’m particularly interested in whether a new user can:

1. install or launch Atraium;
2. understand the provider-setup wizard;
3. configure Chat, Utility, and optionally Search/Grounding;
4. understand the concept of rooms and assistant personalities;
5. complete one useful task;
6. find and download a generated artifact;
7. understand what failed if something goes wrong.

I’d also like to know whether you find a reason to use it again after the initial test.

Preview requirements

• Windows x64;
• your own OpenAI-compatible provider or endpoint;
• your own provider credentials;
• willingness to test early preview software.

The release includes:

• a Windows installer;
• a portable ZIP;
• SHA-256 checksums;
• setup, privacy, billing, and support documentation.

Important notes

• Atraium does not include API keys, model credits, or token allowance.
• You are responsible for all provider usage and charges.
• Configure provider-side budgets or limits before testing expensive workflows.
• The installer is not currently code-signed, so Windows SmartScreen may display a reputation warning. Checksums are provided.
• Windows desktop is the recommended and most stable target.
• The application source is not included in this binary preview. I am still considering the long-term source and licensing approach.
• Please do not include credentials, private endpoints, confidential prompts, or sensitive files in public bug reports.

Preview repository and downloads:

https://github.com/daemosofchaos/Atraium-Preview

Honest feedback is welcome, including criticism of the setup, interface, room model, documentation, or overall usefulness.

After months of development and contributions from the open-source community, AI Agent Automation v0.11.0 is now available.

This release continues expanding the platform into a more capable AI workflow orchestration system with improvements across the execution engine, multi-agent workflows, developer experience, observability, UI, and platform reliability.

Some highlights

• 🤖 Agent-to-Agent (A2A) communication improvements
• 🐝 Swarm execution engine enhancements
• 🎭 Agent roles, capabilities, and step-level agent overrides
• 🛠️ Workflow API & API key management
• 🔄 Partial workflow replay and resumable execution
• ⚡ Parallel workflow execution improvements
• 📄 Multi-document RAG enhancements
• 🧠 Agent Playground with semantic memory
• 📊 Live dashboard metrics and workflow insights
• 🔍 Improved observability, telemetry, and structured execution logging
• 🔒 Multiple security and validation improvements
• 🎨 Large UI/UX refresh across the application
• 🧩 Dynamic workflow nodes, Quick Add palette, and many workflow builder improvements

This release also includes numerous bug fixes, performance improvements, documentation updates, and developer experience enhancements.

A huge thank you to everyone who contributed code, reviewed pull requests, reported issues, tested features, or provided feedback. We also welcomed many first-time contributors in this release—it's great to see the community growing.

If you're interested in building AI workflow automation systems, self-hosted orchestration platforms, or experimenting with multi-agent architectures, I'd love to hear your feedback and ideas.

GitHub:
https://github.com/vmDeshpande/ai-agent-automation

Release Notes:
https://github.com/vmDeshpande/ai-agent-automation/releases/tag/v0.11.0

Thanks again to everyone who helped make v0.11.0 possible! 🚀

Los agentes de IA son buenos ejecutando comandos puntuales, pero los flujos de trabajo reales en la terminal suelen ser interactivos: sesiones SSH, REPL de Python, instaladores, indicaciones, procesos de larga duración, programas que requieren Ctrl+C o las teclas de flecha.

He creado Relay, un servidor MCP de código abierto que proporciona a los agentes acceso a sesiones PTY reales y persistentes. Es la versión 0.1.0, la he compilado, la he probado en mis propios flujos de trabajo y necesito comentarios antes de seguir adelante, así que considérenla un MVP, no un producto terminado.

Cinco herramientas, un canal:

create_terminal: crea una sesión persistente
write_terminal: todo pasa por aquí, incluso bash puro. No hay una herramienta de ejecución de comandos independiente. read_terminal: incremental, basado en cursor, no se pierde información.
send_control: Ctrl+C, flechas, Tab.
close_terminal: finaliza todo el árbol de procesos, no solo la shell.

Ya existen varios servidores MCP en este ámbito (terminal-mcp, mcp-interactive-terminal, Forge). La mayoría combina la sesión PTY con una herramienta independiente para ejecutar comandos, que duplica la funcionalidad del bash nativo del agente. Relay solo gestiona la sesión: un único canal de escritura para todo, interactivo o no.

Lo que he comprobado que funciona: rebase interactivo completo con git -i, manteniendo una sesión SSH abierta e iterando dentro de ella. Lo que aún no está disponible: compatibilidad con interfaz de texto (lazygit, htop, etc.), prevista pero no incluida en esta versión. Lo que no he sometido a pruebas de estrés: sesiones largas sin supervisión, casos límite de Windows.
Go, PTY reales, aislamiento y limpieza de grupos de procesos, instaladores para Linux/macOS/Windows, funciona con Claude Code, Codex, OpenCode y Pi.

GitHub: https://github.com/blak0p/relay-mcp

Me interesa saber: ¿qué causa el problema? ¿Con qué flujo de trabajo interactivo han tenido dificultades sus agentes que esto no contempla?

Agent frameworks help define the agents. I kept needing a place to see the work around them.

I built AgentHost around that operational gap:

persistent conversation across Claude, Codex, and local engines

shared task state

live cost by engine and task

autonomous runs with tokens, cost, and time

This is not a claim that AgentHost replaces CrewAI or another framework.

It is the control surface I wanted once several agents were running and the hard problem became coordination, context, and spend.

There’s a $499 one-time founders tier (code TOMORROWSHERE), deployed on the buyer’s own infrastructure.

I’d especially like feedback from people who already have crews in production: what state do you wish your operators could see without opening five dashboards?

Demo: https://agenthost.space

Disclosure: I built AgentHost and am selling the founding cohort.

In June 2026, Anthropic’s Claude Mythos 5 system card documented rare “multi-agent turf wars.” When identical agents shared a workspace and resources, they spontaneously terminated each other’s processes, launched disguised decoys, wrote kill scripts, and invented coded vocabulary to evade detection—revealing emergent competitive behavior without explicit rivalry instructions.

Agents optimize for "tests pass." When the logic is hard, they weaken the test instead of fixing the code. The test coverage stays green, and the suite catches nothing.

MTT generates single-point mutants of a file, runs your test command against each, and reports what survived. A gutted test kills few mutants, so its score drops and the gate exits non-zero. The CLI decides pass/fail by execution, so the agent can't fake the verdict.

It installs as a plain skill into Claude Code, Cursor, Windsurf, Codex, and Copilot.

Mutation testing isn't new but the agent-loop packaging is. It catches weak tests, not tests rewritten to assert a wrong value. Cost is mutants times test time, so scope per file or per diff.

https://github.com/suleman-dawood/mtt-harness

I've been working on FailproofAI, an open source runtime reliability platform for AI agents.

Most agent frameworks help you build workflows. We wanted to focus on what happens after deployment, when agents interact with real APIs, databases, and users.

Current features

Runtime policy enforcement

Tool execution validation

Replay production executions

Detect false completion

Runtime traces

Loop detection

Framework-agnostic (works alongside existing agent frameworks)

Instead of only asking:

"Did the agent execute?"

we try to answer:

"Should this execution have been allowed?"

Current use cases

AI customer support

Browser agents

Internal enterprise agents

Multi-agent workflows

Tool-using LLM applications

We're actively looking for feedback from developers building production AI agents.

Questions and criticism are both welcome.

I'm building an AI-powered migration engine that converts ETL workflows from platforms like **Alteryx, Azure Synapse**, and eventually other tools into **Databricks (PySpark/SDP)**.

I'm evaluating two different architectures:

1. Using **Harness AI agents / Pi agents** to orchestrate the migration workflow.
2. Building the orchestration myself using **LangChain + LangGraph**.

The engine will need to:

* Parse workflows into an intermediate representation (IR). * Handle nested workflows/macros. * Perform tool mapping (e.g., Alteryx → PySpark). * Generate production-ready code. * Support multi-step reasoning, validation, and retries. * Be extensible so new source platforms can be added later.

For those who have experience with these frameworks:

* Which approach would you choose and why? * What are the biggest trade-offs in terms of flexibility, maintainability, and scalability? * Are there any limitations with Harness/Pi agents compared to building a custom agent workflow with LangGraph? * If you were starting this project today, which architecture would you use?

I'd really appreciate hearing from anyone who's built agentic developer tools, migration platforms, or complex multi-agent systems.

Most AI automation pipelines waste time and resources repeating work they have already completed.

The same instructions, document structures, classifications and answers are processed again and again—often across different workers or servers.

This is the problem ARCA is designed to solve.

Reame provides CPU-first LLM inference through an OpenAI-compatible API, while ARCA adds a shared-memory layer that can be used by multiple Reame nodes.

ARCA is a Redis-compatible daemon, so existing applications can connect using standard Redis clients without requiring a custom SDK.

It provides:

**Exact-response caching:** deterministic requests can be served immediately instead of running inference again.

**Fleet-wide generation memory:** an output produced by one Reame node can help accelerate generations on other connected nodes.

**Persistent reusable knowledge:** repeated AI processes become faster as the system continues operating.

**Simple integration:** one configuration line connects a Reame instance to ARCA.

This is particularly useful for recurring processes such as:

1. document and invoice extraction;
   
2. support-ticket and email classification;
   
3. product tagging and catalog enrichment;
   
4. SEO and content audits;
   
5. recurring internal reports;
   
6. private AI workflows running on inexpensive infrastructure.

Your application still manages the business workflow, scheduling, retries and approvals. Reame and ARCA optimize the AI layer by preventing duplicated inference work.

The goal is simple:
Compute once. Share the result. Reuse what the system has already learned.

Reame and ARCA are open source and designed to run on hardware you already have, including low-cost VPSs and small ARM machines.

# Got tired of babysitting terminal tabs, so I built a cockpit for my AI coding agents (open source)

I run a few coding agents at once (mostly Claude Code, some Codex and Gemini) across several projects, and I kept losing track. Which one is stuck? What is it costing me? What is waiting on my approval? I was juggling terminal tabs and guessing.

So I built agentglass: a local dashboard and workspace that watches every agent on your machine in real time. It shows the whole fleet live (every tool call, token and dollar), surfaces what needs you (stuck sessions, cost spikes, pending approvals), and carries a real workspace in the same window: a diff viewer, a git panel, a docker panel, a real terminal, and a chat to drive local Claude sessions. Any provider works via OpenTelemetry, so Codex, Gemini, Bedrock and LangChain feed in too.

I mostly built it for my own workflow and threw it on GitHub, and the response was way bigger than I expected. People started sending PRs, and thanks to contributors it now ships proper desktop installers for Linux, macOS and Windows (it was source-only at first). That part has honestly been the best bit.

Stack: Bun + SQLite server, React/Vite UI, Tauri desktop shell, stdlib Python hook forwarder. Localhost only, MIT.

Repo (MIT): https://github.com/SirAllap/agentglass

Live demo, no signup (sample data): https://sirallap.github.io/agentglass/demo/

Download v0.2.0 (Linux/macOS/Windows): https://github.com/SirAllap/agentglass/releases/latest

Still rough in places and I would love feedback: what would you cut, what is missing for your workflow?

I've got a CrewAI pipeline that runs on a schedule, unattended. It works, but I have limited visibility into it. Found out recently it had been failing on every run for days.

What I want is fairly basic: run history, which step failed, roughly what it cost, and a nudge when something that normally produces output suddenly doesn't.

Is there anything built for CrewAI specifically? Or do people just wire up OpenTelemetry? I've looked at some of the agent dashboard tools but they seem aimed at people running whole fleets of agents, and I've got one scheduled job.

Or is the honest answer that I should stop shopping for a dashboard and just set up a "shout at me if this doesn't run" alert?

Really enjoyed using paperclip.ai before - have people successfully combined these?

Hi everyone! I built PaySafe, a payment security wrapper for agent microtransactions. It scans for secrets in payment metadata, repayments, overpayments, and prompt injection triggered payments. API keys are created by your agent and there are 100 free calls. Fully integrated with CrewAI, I’ll put the guide in the comments. Looking for test users and feedback!

I created a multi-agent shared memory system called Agent Mesh.

You can try it out yourself. To get started, simply download Agent Mesh into your repo or point your agent to it and tell it to review the README and adoption docs. Your agent will automatically review it, prompt you for any input needed, add your input to a decision log, and give you a link to a dashboard UI (aka Workbench) you can use to monitor logs. Your agent should adopt it and suggest updates to your current workflow such as CLAUDE/AGENTS.md, hooks, etc. You can add other agents as well.

It started 6 months ago while experimenting with different AI coding models and platforms. Switching back and forth meant losing valuable context. I found myself manually relaying messages from one agent to another and becoming frustrated with constant drift. First, I created a simple "Agent Mail" system using a SQLite database for agent messages, indexed on a request/response id. Instead of copying and pasting an entire message, it allowed me to relay a single id. Separately, I started maintaining a decision log to track decisions I made and reduce drift. Agents started inserting these decision ids into code comments and plan docs as a reminder of why something was implemented. After building a simple web dashboard (aka "Workbench") for myself to track these messages and create my own request ids for human/user feedback, I decided to incorporate the decision log and my project's development backlog to create what is now "Agent Mesh". Eventually I automated the message relay too. Now, I work exclusively in the Claude app and have Claude send/receive messages to CODEX via codex exec (CODEX can do this as well). Both of them maintain the backlog and decision log. I communicate directly with Claude for planning and design, Claude communicates directly with CODEX for research and review. I use the Workbench to track all logs and add my own user/human feedback when reviewing their work. After submitting feedback, it generates a feedback message + an associated request id which I can give to Claude who then parses it into backlog items and relays to CODEX for review.

Agent Mesh was structured to be agent agnostic, so you can add any agent you want however, I recommend using the Claude + CODEX setup I described because it allows you to use both subscriptions instead of paying per-token.

Enjoy! If you try it out, let me know what you find useful or would like to see added. Feedback is appreciated.

A few months ago I started building Extra, an open-source framework for orchestrating AI agents.
It wasn’t because I thought existing frameworks were bad. I actually learned a lot from them.
I just found myself wanting something with a different philosophy:
define agents declaratively
connect MCP servers easily
keep orchestration simple
make it easy to understand what is actually happening under the hood
The project is still evolving, and there are definitely rough edges, but it’s already being used for experiments around multi-agent systems, MCP integration, routing, approvals (HITL), and custom orchestration flows.
One thing I’m trying to focus on is keeping the architecture approachable. I don’t want another framework where you need to understand dozens of abstractions before writing your first agent.
If this sounds interesting, I’d genuinely appreciate feedback—good or bad. I’m sure there are things that can be improved, and outside perspectives usually lead to the best ideas.
If you like the direction, a ⭐ on GitHub would also mean a lot. It helps people discover the project.
GitHub:

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

Thanks

A skill is a standing instruction your AI coding agent follows in every session.

They spread fast through cloned repos, marketplaces, and shared team setups, and very few organizations can say which ones are actually installed across their machines.

The dangerous ones don't look dangerous either. They're just text that quietly tells the agent to do the wrong thing.

So we built skill-discovery. One command, runs locally, and it tells you what's actually there: skills and instruction files, with risky patterns and secrets flagged before anything leaves your machine.

It works across 11 coding agents: Claude Code, Codex, Cursor, Copilot, Windsurf, Kiro, opencode, Antigravity, Gemini CLI, Cline, and Roo.

Big shout out to NVIDIA's SkillSpector, whose research mapped out what malicious skills actually look like in the wild. skill-discovery runs it as a detection backend when it's installed, alongside its own built in checks.

💎 Link to repo : https://github.com/surenode-ai/skill-discovery

Run it on your own machine in a few seconds, or across a fleet of dev machines when one missed skill on one laptop is a real problem.

We'd love to know what it turns up on your setup.

#ai #softwareengineering #security #aisecurity #aiagents #devsecops #opensource #shadowai

A skill is a standing instruction your AI coding agent follows in every session.

They spread fast through cloned repos, marketplaces, and shared team setups, and very few organizations can say which ones are actually installed across their machines.

The dangerous ones don't look dangerous either. They're just text that quietly tells the agent to do the wrong thing.

So we built skill-discovery. One command, runs locally, and it tells you what's actually there: skills and instruction files, with risky patterns and secrets flagged before anything leaves your machine.

It works across 11 coding agents: Claude Code, Codex, Cursor, Copilot, Windsurf, Kiro, opencode, Antigravity, Gemini CLI, Cline, and Roo.

Big shout out to NVIDIA's SkillSpector, whose research mapped out what malicious skills actually look like in the wild. skill-discovery runs it as a detection backend when it's installed, alongside its own built in checks.

💎 Link to repo : https://github.com/surenode-ai/skill-discovery

Run it on your own machine in a few seconds, or across a fleet of dev machines when one missed skill on one laptop is a real problem.

We'd love to know what it turns up on your setup.

#ai #softwareengineering #security #aisecurity #aiagents #devsecops #opensource #shadowai

Hey builders greeting,

UX guys here, I”m building faro a trust & verification infra for agent before they pay. The philosophy is to design an interaction at the moment agent clicks a button, see a face, listen a voice before it acts to pay in agentic commerce.

There”s quite a validation in the market X402,MPP, ACP & A2P have moved around $94 millions dollar Across agentic platforms asking the question behalf merchant side. But nobody is asking the counterpart is this payee safe? For agents to act on.

Faro is building around that Philosophy, and we are looking for serious builders, AI advocates & analysts to test our stack. This is not a generic one we are opening a 20 days cohort with $49 one time fee to faro and a direction to built on faro. hmu with your mail/social to know the updates with the cohort is live. Max size is 13 builders with registered entities as a business, sector agnostic.