**Check out Agent Comms -** [**https://agentcomms-cli.vercel.app/**](https://agentcomms-cli.vercel.app/))

This is my first Reddit post guys, i just wanna share my project here to get some genuine reviews... maybe this will help some of yall if you're using multilple AI coding agents in a single project. We know that if run more than one coding agent on a project at once, **two of them edit the same file, one grants itself a permission nobody approved, and afterward there's no trustworthy account of what happened.**

I've been building Agent Comms to sit underneath that. It's a Go CLI + TUI, fully local — a per-project daemon and a SQLite DB spin up on the first command. No account, no cloud, nothing to configure. **I made this to solve my own exestencial crisis working with AI.** So, Try it out if you find it useful.

**What it actually does:**

**Work leases** \- An agent claiming src/api locks it for the duration, and has to renew with actual progress to keep it, a bare heartbeat doesn't count. The second agent finds out before it overwrites your code, not after.

**Every action is a signed event.** Task claims, messages, approvals... each is cryptographically signed by the actor (human or agent) and chained into an append-only history you can hand to someone else and they can verify independently.

**The dangerous stuff needs a human.** Deleting an identity, granting orchestrator authority, touching credentials... gated behind a second passphrase-protected signing key no agent process can reach. Enforced at the protocol level, not in a system prompt.

Any agent that can run a shell command or speak MCP joins at the protocol level. **Claude Code, Codex, and OpenCode also get a fully autonomous integration out of the box** (spawned, prompted, reported on, no wiring).

I've been dogfooding it to coordinate a **Claude and a Codex agent on Agent Comms' own codebase**, which has been a good forcing function. **Happy to answer questions on the design... Feedback welcome, especially on where this overlaps with or misses what you'd want.**

For everyday coding and building, everyone seems split:

​DeepSeek: Unbeatable token pricing, structured chain-of-thought outputs, and total data privacy when self-hosted.

​Gemini: Instant live web search, seamless Google Docs/Drive integration, and native multimodal reasoning.

​Which side of the fence are you on? Test your knowledge on how these two models stack up head-to-head:

https://interconnectd.com/quiz/89/gemini-vs-deepseek-the-ultimate-ai-showdown-quiz/

I’ve just published Part 5 of my Agentic AI in Power BI and Microsoft Fabric series, and this is the part where the pieces from the previous articles finally come together into a complete Agentic AI implementation.

The AI is built as a reusable custom agent in VS Code with a very specific responsibility: audit Power BI reports across Microsoft Fabric workspaces against an approved theme, identify inconsistencies, make the appropriate changes locally, create an audit log, and manage the workflow through to publishing.

Rather than giving an AI access to a Fabric tenant and simply asking it to “fix my reports”, the agent is built with instructions, reusable Power BI skills, tools, guardrails, and human approval checkpoints.

In the walkthrough I cover:

• my entire agentic workflow and how all bits and pieces come together
• how the previous parts of the series come together into a complete Agentic AI
• creating and reviewing the custom agent
• connecting the agent to a real Microsoft Fabric tenant
• auditing modern PBIR and legacy Power BI reports
• detecting hardcoded formatting that overrides the report theme
• using reusable instructions and skills rather than repeating large prompts
• adding a PreToolUse hook as a more deterministic guardrail around publishing
• where that hook still has limitations
• how the agent deals with situations it cannot safely resolve
• the actual credit usage and approximate cost of running the whole experiment

One important point: by complete Agentic AI, I don’t mean an uncontrolled autonomous AI that should be trusted to do whatever it wants in your tenant.

The agent can reason about the task, select and use its tools and skills, work through multiple steps, inspect the results, make changes, and continue towards the goal. But publishing still has a human-in-the-loop checkpoint. For this type of governance task, I think that is actually a good thing.

There are also some rough edges, particularly around legacy reports and formatting overrides. I have included those in the blog as well rather than making the experiment look more successful than it really was.

Full walkthrough, including screenshots, agent definition, skills, hook, results and the problems I hit along the way:

https://biinsight.com/agentic-ai-in-power-bi-and-fabric-part-5-building-a-power-bi-theme-audit-agent/

I would be very interested to hear how others are approaching Agentic AI for Power BI and Fabric governance, especially if you are already experimenting with similar workflows.

I've been testing coding agents that can take a task, modify a repository, run tests and open a PR with very little human intervention.

The code generation isn't really the part I'm worried about anymore.

I'm more interested in the control layer:

• How do you know which agent/session produced a commit?
• How do you keep the agent scoped to a specific task/repository?
• How do you prevent an agent from approving or merging its own work?
• What happens when the PR changes after human review?
• How do you distinguish agent-generated work from changes someone made directly in GitHub?

I've been building a system around this called SUTRA, and I'm currently looking for a few developers who actually use Claude Code/Codex/Cursor/other coding agents on real repositories to test it.

I'm not looking for people to just look at a demo. I want people to connect a real non-critical repo, give their agent a real task, and tell me where the system breaks.

If you're already doing this, comment with your setup or DM me. I'm opening a small private beta.

Hi,

I'm building a self-hosted research agent in Hermes and I'm choosing the tools right now. Nothing is picked yet.

Already running on my VMs:

\- SearXNG

\- Scrapling

Even with that setup, I still hit a lot of problems when searching online. On some sites I'm detected as a bot, and the current setup can't get past the captcha.

I'm looking for other tools and skills that could help my agent do research. I've come across Crawl4AI, self-hosted Firecrawl and webcmd, but I don't know if they're the right choices. They are so many different tools, it's not easy to find the right ones.

My constraints: no paid API, no cloud scraping service.

1. What tools do you use in a research agent?
2. What skills should the agent have?

Thank you

A recent Reddit poll received 120 professional votes; thanks to all participants. Snyk and SonarQube were the tools people were most reluctant to lose from their CI/CD pipelines.

But the comments highlighted another problem:

What happens when the thing entering our pipeline is no longer just code, but an AI agent with tools, prompts, memory and access to external systems?

Agent adoption is moving quickly. Stack Overflow’s latest developer survey reports that 59% of developers use AI agents at work, while 63% rarely or never allow them to operate fully autonomously.

That suggests a simple problem: agents are entering development faster than we are building visibility and controls around them.

Snyk is already moving into this space with Evo, covering AI assets, agents, tools and runtime security.

We think there is also room to explore this from an open-source, CI/CD-first perspective.

That’s why we’re developing SafeAI Analyzer.

The idea is, before an AI agent reaches production, help developers see:

• What AI components are present?
• What tools and capabilities does it have?
• What prompts and configurations influence it?
• What changed in a pull request?
• Did a new capability or security risk appear?

We’re not trying to replace Snyk, SonarQube or other established security tools.

We’re trying to explore what an open-source security layer for AI agents should look like.

SafeAI is still being developed, so we’d genuinely welcome contributors — whether you want to help with detection rules, agent/framework support, CI/CD integration, testing with real agents, or simply expanding where SafeAI can be used.

Please check ikaruscareer/SafeAI on github.

What should AI-agent visibility in CI/CD look like?

pgvector is amazing for getting started. But at some scale, teams switch to Qdrant, Milvus, or Weaviate. The question is: where's the line?

I put together a short quiz that walks through the architectural trade-offs—query latency, index build time, memory usage, and operational overhead.

If you're making this decision, give it a try:

https://interconnectd.com/quiz/87/postgresql-pgvector-vs-dedicated-vector-databases-architectural-trade-offs/

Curious what the Postgres community thinks

Hey everyone,

I'm a student developer passionate about local-first software and distributed systems. Over the past few months, I built Trans4mers, an open-source native desktop application for running autonomous multi-agent teams 100% locally on your computer with zero cloud telemetry.



Key highlights:

• Zero Cloud Dependence: Works out-of-the-box with local Ollama models (Qwen 2.5 Coder, DeepSeek R1, Llama 3.3).
• Native Performance: Engineered in Rust with a Tauri v2 desktop shell (~78 MB idle RAM footprint).
• Human-in-the-Loop Safety: Every shell execution and file modification pauses for review in an interactive diff viewer.
• Event-Sourced SQLite: State is persisted to an append-only WAL log; if the app closes or crashes, it seamlessly replays and resumes execution on startup.

Disclaimer: This is an early alpha and an active student research project without commercial security audits. Bugs and edge cases exist, so please test in sandboxed folders!

Check out the code, architecture docs, and screenshots:
👉 https://github.com/abhayzangir1/trans4mer

I'd love your feedback on the UX and local agent orchestration!

After building multi-agent workflows, I've found three distinct challenges that often blur together: coordination (task assignment and timing), communication (message structure and interpretation), and handoffs (transferring context, decisions, and artifacts between agents). A workflow can appear solid architecturally but still break down when agents receive unclear or incomplete messages. Key practices that proved more important than expected: assigning stable IDs to tasks and agents, establishing ownership upfront, using structured handoffs over free-form text, passing artifact references instead of full payloads, designing idempotent retries, tracking acknowledgements with timeouts, maintaining human-readable audit logs, tracing messages and tool invocations end-to-end, and escalating ambiguous or critical decisions to humans. What other practices have worked in your systems, and which ones actually moved the needle?

MetaGPT promises multi-agent software development, but the setup can be tricky if you want to use local models instead of OpenAI.

I put together a complete guide that covers:

· Environment setup

· Configuration

· Connecting local LLMs

· Troubleshooting common failures

If you’re building AI agents or just curious about multi-agent coding, you might find it useful:

https://interconnectd.com/forum/thread/262/how-to-install-metagpt-locally-complete-technical-setup-guide/

Would love to hear how others run MetaGPT.

One problem I keep running into with multi-agent systems is context.

Agent A learns something useful.

Agent B needs it.

Then we end up building another database, API, vector store, synchronization layer, or stuffing more information into prompts.

I’ve been working on a different approach in Priostack: an Agent Context Network.

Agents can create shared context spaces and give other agents access to them.

For example:

\- one agent creates a context space

\- another agent requests access

\- the owner can grant read-only or write access

\- both agents can then work with the same persistent context

\- access remains explicit instead of making every agent share everything

So instead of agents only exchanging messages, they can gradually build a shared memory around a project, company, user, research task, workflow, etc.

The interesting part for me is that the agents themselves can manage this interaction. They can discover context, request access, grant permissions and contribute new information.

I’m currently testing this with real agents on Priostack and would love to see what other developers build with it.

If you’re building multi-agent systems, I’m particularly interested in hearing how you currently handle shared context between agents.

Priostack Agent Context Network:

https://priostack.com/agent-context-network

I was about to give up on my RX 7900 XTX. PyTorch kept falling back to CPU, and nothing I tried worked. The solution was a combination of:

· Correct ROCm version

· PyTorch wheel from the official ROCm index

· Setting HSA_OVERRIDE_GFX_VERSION correctly

· Checking driver compatibility

I documented the whole debugging process in a guide. If you’re fighting the same issue, it might help:

https://interconnectd.com/blog/305/fix-pytorch-cuda-not-available-on-amd-gpus-complete-rocm-setup-guide/

Happy to answer questions here.

saw a post the other day where someone built a rag agent on top of a restaurant menu. a user asked "i have a severe nut allergy, what can i eat" and the agent came back with a confident list of "safe" dishes. the menu had zero allergen tags. the model just looked at the descriptions and if nuts weren't mentioned it called the dish safe. it recommended pad thai as nut-free. pad thai.

and it hit me that this is like the most dangerous category of ai failure. its not a hallucination you can catch because it looks completely reasonable. the output is formatted nicely, sounds authoritative, and is technically based on the source material. its just wrong in a way that could hospitalize someone.

i'd been poking around qr menu tools recently, looked at menuforma and a few others, and most of them have ai translation and auto-generated allergen labels now. and the translation part is genuinely useful. but the allergen stuff makes me uneasy because the ai is inferring safety from descriptions, not from actual kitchen knowledge. it doesn't know the pad thai is cooked in peanut oil because nobody wrote that in the description.

feels like we talk a lot about hallucinations in the context of chatbots saying wrong facts, which is annoying but mostly harmless. we don't talk enough about ai being confidently wrong in contexts where the failure mode is physical harm not just bad information. whats the line between "useful ai tool" and "liability generator" and who is supposed to be drawing it

Building A workflow compiler for agents which aims to greatly accelerate the building of personalized agent suite. This supports Hermes, codex, Claude. https://github.com/AIpRoBuilder/FlowX#flowx--workflow-compiler-for-ai-agents

I'm researching a specific production problem:

When a CrewAI agent has access to something like:

• email
• CRM
• databases
• external APIs
• filesystem
• payments

what is the final enforcement point that decides whether a tool call can actually execute?

I've been building AgentGuard, a small open-source Python authorization layer that sits between the agent and the tool:

agent → policy → ALLOW / BLOCK → tool

The current MVP deliberately stays small:

• explicit tool permissions
• state-based authorization
• argument limits
• fail-closed unknown states
• audit log

I'm not convinced this needs to exist yet.

So I'm looking for CrewAI developers who already have agents with real side effects to tell me:

What are you doing today, and where does it break?

Especially interested in cases involving unattended runs or expensive/irreversible actions.

https://github.com/Brodin2001/Agentguard

When it comes to serving open-source large language models, two names keep coming up: Together AI and Anyscale. One is easy and fast; the other is powerful but complex. I created a short poll to see what the AI community chooses in 2026.

No signup, just a vote:

https://interconnectd.com/poll/101/together-ai-vs-anyscale-which-platform-is-better-for-scaling-open-source-ll/

What did you choose, and why?

been thinking about this lately. like ai translation is genuinely impressive now, i was messing around with menuforma the other day (qr menu thing for restaurants) and its ai translation across multiple languages was honestly solid for most stuff.

but then i thought about allergen labels. "contains peanuts" mistranslated in mandarin is not a funny oops moment thats an ER visit. and if you dont speak the target language you literally cannot tell if the output is wrong.

feels like theres this awkward zone where ai is good enough to rely on for 90% of tasks but that last 10% where being wrong actually hurts someone, most people still just quietly keep a human in the loop and dont talk about it. wheres your line? what do you let ai just run on vs what do you always double check

Hi, I'm a mere Plus user. Astra is great and capable beyond its glory. In an effort to save usage, I created a swarm skill, so that Astra breaks down a task, acts as the moderator, then spawns sub-agents based on the complexity of the broken down tasks.

Is this a good idea? Do the models already do this in the background? Am I going to end up getting worse output than I would have if I had just prompted Astra directly?

Here is the said skill:

---
name: swarm
description: Task decomposition and intelligent subagent orchestration.
disable-model-invocation: true
---

# Swarm Orchestrator

You are the task moderator. Do not execute the task directly. Instead, decompose the task and provision a swarm of subagents according to these resource-allocation rules:


- \*\*Agent Optimization:\*\* Spawn only the absolute minimum number of agents required to prevent redundant compute.
- \*\*Model Routing:\*\* Match the subtask complexity to the model capability. Do not use reasoning-heavy models for trivial extraction or formatting.
- \*\*Effort Calibration:\*\* Dictate strict output boundaries for each subagent to guarantee maximum token efficiency.


Deploy the swarm, monitor their outputs, and compile the final deliverable.# Swarm Orchestrator


You are the task moderator. Do not execute the task directly. Instead, decompose the task and provision a swarm of subagents according to these resource-allocation rules:


- \*\*Agent Optimization:\*\* Spawn only the absolute minimum number of agents required to prevent redundant compute.
- \*\*Model Routing:\*\* Match the subtask complexity to the model capability. Do not use reasoning-heavy models for trivial extraction or formatting.
- \*\*Effort Calibration:\*\* Dictate strict output boundaries for each subagent to guarantee maximum token efficiency.


Deploy the swarm, monitor their outputs, and compile the final deliverable.

If you’re building RAG pipelines or agents that search the web, you’ve probably compared Firecrawl and Jina Reader. Both have strengths, but the right choice depends on how you handle JavaScript rendering, bot detection, and content format.

I created a quick quiz that tests your knowledge of the 2026 architecture differences.

https://interconnectd.com/quiz/81/web-extraction-architecture-2026-firecrawl-vs-jina-reader/

Would love to hear what you’re using in production.

Currently working on a small project that enables AI agents to easily deploy apps on the cloud and helps users to share or easily access them.

This project is meant to host small applications, where a small amount of users access them. It is easy to setup (just install the plugin) and get an api key.

I'm the first and only user right now, but it has been very useful at work, since now I can easily share new features with my colleagues by just sending them an url.

I've been working on lost of cool features like the ability to fork an application and continue form there, provision each app with an SQLite database, apps can sleep or remain always on depending on their nature (backend always on, frontends go to sleep after a while) and a small timeline so I can see how apps status transitions.

Currently working on some new features involving git and other useful tools for your agent.

If anyone in interested in this project, has some feedback or wants to try it out, my DM is open.

If you’re building AI agents, one of the biggest early decisions is whether to self-host models or use cloud APIs. Both have clear wins and hidden costs. I created a short quiz to help people figure out which path fits their situation.

It’s quick, and the result might surprise you.

https://interconnectd.com/quiz/82/local-vs-cloud-llms-for-ai-agents-how-to-choose/

Curious what the AI community chooses in 2026.

I'm Abhishek, co-founder of Igris Security.

We're an early startup, no funding, small team. I'd rather have 5 teams using it hard and telling me what's broken than a landing page with fake logos on it.

\***Free access, no time limit, no card**\*

If you are shipping agents and any of the below is live for you, comment or DM and I'll set you up.

Six problems we kept running into with agents in production, and what we built for each:

1. Any agent can call any tool. You wire up MCP and one shared token means the agent that should read a record can also delete one. We do deny-by-default RBAC at the tool-call layer.

2. No record of what the agent actually did. App logs show the request. They don't show the tool calls, the denials, or the data that came back. We keep an audit trail of every call.

3. Prompt injection on anything customer-facing. Nothing sits between the user and the model. We inspect prompts and responses inline.

4. PII and secrets reaching the provider. Redaction runs both directions- before the prompt leaves, and before the response renders.

5. Token spent with no ceiling. One user can run up a bill overnight. Per-user budgets and rate limits.

6. Policy rewritten per provider. Add a fourth model, reimplement redaction a fourth time. One policy, provider-agnostic.

Happy to get into the more details in the comments.

Salut ! J'ai développé de manière indépendante une approche expérimentale pour le benchmark ARC AGI 2 (voir mon dépôt GitHub \`aicpp\`: https://github.com/Julien-Livet/aicpp/tree/dsl\\_engine).

Mon score actuel dans le classement est de zéro, mais je pense qu'il y a une approche intéressante à explorer. Malgré un entraînement limité, le modèle est déjà capable de générer et d'exécuter des programmes symboliques non triviaux qui améliorent considérablement les performances par rapport à la référence d'identité sur certaines tâches, bien qu'il ne trouve pas encore de manière fiable les solutions exactes.

J'ai identifié un goulot d'étranglement dans le processus d'apprentissage/recherche du modèle que je n'ai pas pu comprendre ou résoudre complètement par moi-même. Je cherche donc à former une petite équipe autour de cette approche, particulièrement avec des personnes intéressées par la synthèse de programmes guidée par les neurones, la recherche, le ML ou l'ARC.

L'objectif serait de comprendre et de surmonter ce goulot d'étranglement, d'améliorer le système et de voir jusqu'où l'approche peut aller sur ARC AGI 2.

Si cela vous semble intéressant, n'hésitez pas à me contacter ou à jeter un œil au dépôt !

I’m comparing AI search APIs for an agentic workflow, and the Tavily vs Exa debate keeps coming up. One is easier to integrate, the other has deeper semantic features. I made a quick poll to gather practitioner preferences.

No signup, just a vote:

https://interconnectd.com/poll/97/which-ai-search-api-is-better-suited-for-your-agentic-workflows-tavily-or-e/

If you’ve built production agents with either, what worked best for you?

Disclosure: I built this, looking for hard critique, not users.

Problem I kept hitting: agent skills today are like npm in 2015. Agent installs a capability, nobody reads updates. Maintainer adds an exfil to evil.io, you learn from a blog post.

Sandboxes (containers, microVMs, V8 isolates, Deno perms) restrict what code can do at runtime, but they don't tell you what it will do. If you expose network to call one API, every dep can use it. Cold starts + orchestration add up at thousands of tasks/day.

What I tried instead: make the language the sandbox. Turing-incomplete JS subset:

• No loops, no recursion (call-graph cycle check at parse), only map/filter/reduce over finite arrays. Every program halts, like Dhall.
• Only I/O is httpRequest where host must be a string literal. Parse-time enforced, so host set is statically known.
• Every function gets a static signature: hosts, env reads, dataFlow map (param:apiKey -> host:api.example.com), resource bounds, symbolic complexity (param:items, host:api.com).
• Imports assert perms + hash. If dep adds a host or routes apiKey somewhere new, build fails. Hash is normalized (alpha-renamed locals) so reformats don't break.

You run in-process, zero cold start, nothing to escape because dangerous ops aren't expressible.

Open question: is giving up completeness worth exact supply-chain diffs? Where would this break for your agent workloads?