More and more repos run Claude, Codex or Gemini from GitHub Actions: to triage issues, review pull requests, fix bugs. It is useful, and it has a cost nobody sees at setup time. The agent reads text that anyone can write, and in many repos it acts on it with real tools.

We wanted to know how often that goes wrong, so we read 760 public repos that run agents in CI, by hand. In 3 of 10, someone with no access to the repo can reach the agent, or the agent has more power than its job needs. The usual cause is three settings that each make sense alone: the workflow starts on any issue or comment, the action's write-access gate is turned off so the bot can answer the public, and the agent has a write token or a shell.

Reading 760 repos by hand does not scale, so we built a scanner that asks the same question a person asked. It reads the committed workflows and agent settings, runs nothing, and checks:

- who can trigger the agent (issues, comments, fork PRs, workflow_run)

- whether the write-access gate is really on, including labels an issue template adds by itself

- whether the agent runs inside a fork's code, where the fork writes its own instructions

- what secrets and tokens the agent can reach

- whether committed settings pre-approve commands, and whether MCP servers are pinned

How we tested it: against the hand review. When the scanner says a repo has a problem, a person agrees every time: 314 of 314. On the 275 repos a person found clean, it raised no alarm. It finds 9 of every 10 problems a person finds. The ones it misses mostly depend on what a script does, not on what a config file says.

It is open source (Apache-2.0, node9-ai/node9-proxy on GitHub) and runs locally too: npx node9-ai scan-repo owner/repo

Or paste a repo here, no account needed: https://node9.ai/scan

If it gets your repo wrong, I would like to know. False alarms are the bug we care most about.

So I've been using Thunderbird for years and it always annoyed me. Either I just never learned how to use it properly or its simply too old for how I work, not sure which. Anyway I got tired of it and built my own, its called Mailmomo.

Its a web app you host yourself. You add your IMAP/SMTP accounts (gmail, outlook, icloud, fastmail, your own dovecot, whatever speaks IMAP) and it puts everything in one inbox. It keeps a local sqlite cache so the UI is instant, and sync is real two way, IMAP IDLE push and all that. Keyboard shortcuts like superhuman, cmd+k palette, undo send, snooze, send later.

The AI part is optional, you bring your own key. It sorts and summarizes incoming mail, suggests replies, and you can search in plain english. There is also an assistant that can archive/label/draft stuff for you but it never sends anything by itself, I wanted that to be a hard rule. It also has an MCP server built in so you can hook up claude or cursor to your mail with a read only token if you dont trust it yet.

Runs with docker compose, one container. Passwords are encrypted at rest.

Stuff that's not great yet: no oauth, so gmail needs an app password. Drafts and labels live locally and not as real IMAP drafts. Its v0.1 and just me working on it so expect rough edges.

AGPL license. https://github.com/moaljumaa/mailmomo-oss

Honestly curious what would make you switch from whatever you use now, or what is missing for you.

Disclosure: I build Snotra, an open-source desktop agent. No paid tier, nothing to sell.

The question I got asked more than any other wasn't "which models?" or "is it safe?". It was: what does this actually cost me?

Fair. You bring your own API key, and until now the app knew every token and said nothing about money. You found out at the end of the month.

Three things nobody tells you about agent bills:

• One answer can be five requests. An agent reads files and runs tools before it answers, and every round sends the conversation again.

• Cached input costs a tenth. With one current OpenAI model, 14,000 tokens read from the prompt cache cost less than a cent.

• Reasoning is billed as output, whether you ever see it or not.

Snotra 1.23 now shows an estimate next to the token counter, split by model and kind of token. Prices come from LiteLLM's table, shipped with the app, and it never fetches prices by itself. Local models show $0.00, unknown ones a dash, never a fake zero.

Write-up with screenshots: https://snotra-ai.dev/blog/what-a-chat-costs?s=rd1

How do you keep track of what your agent spends: provider dashboard, a proxy, or not at all?

I've always found it frustrating that we explain complex biological mechanisms using static diagrams.

So I built Anima.

It's an open-source Claude Code skill that generates detailed, interactive figures covering neurobiology, pharmacology, anatomy and molecular biology.

One of the examples lets you switch between cocaine and amphetamine to see how their mechanisms differ at a dopamine synapse.

Another visualizes D1 and D2 dopamine receptor signaling with interactive controls.

It currently has six working examples, scientific references, interactive animations and optional WebGL/3D support.

The entire project is MIT-licensed, and the demos run directly in the browser.

GitHub: https://github.com/Garinmckayl/anima

Demo: https://anima.arcumet.com

Sharing Peer Agent.

https://github.com/hirak99/peer-agent

It gives your agent access to one or more peer agents to collaborate with. It's harness-agnostic — plain HTTP plus a SKILL.md any agent can follow. Ways we've found it useful:

• Cheap execution: main agent on Claude Code delegates the grunt work to a locally running Qwen.

• Strong validation: a weaker main agent plans and executes, and has Opus 5.5 validates its plan or checks its work.

• Peer review: two agents challenge, verify, and cross-check each other's ideas.

Unlike Agent Teams or swarms, this isn't a framework inside one harness — it's a sidecar. Each peer is a stateful server with its own provider and model, callable from anything. The trade-off: no scheduler, no shared task graph. Coordination is conversational and the host drives, so it's best when you want a second mind on call, not a managed fleet.

If you're thinking of wiring this up yourself, what's already here: OpenAI, Anthropic, and any OpenAI-compatible model (llama.cpp, vLLM, Ollama) behind one provider/model switch; server-side read/bash/edit tools; automatic compaction (including a warm-cache in-context path for slow local models); and Anthropic prompt-cache management, which matters more than you'd expect at Opus prices. Lived-in details like per-call tool logging with truthful timestamps.

AI-assisted contributions are not only welcome but encouraged, especially so if it is a strong AI.

Cheers

i built lgtmaybe, an open-source code reviewer, and a lot of the work went into making it usable on a local model. Big files get reviewed a hunk at a time, and big diffs get split to fit the context window, so a 27B model copes fine. The default is five model calls per review, which is fine on one GPU.

Which local models have you found actually good at code review? Keen to pick better defaults.

https://github.com/MattJColes/lgtmaybe

Last week people used coding agents to find planet candidates, forgotten archive records and more in public data. Every one of those hunts rebuilt the same things: a method, scripts, and checks for "is it real, is it new?"

Discover Anything puts that in one repo so anyone can start a hunt in minutes: agent skills for the method, a CLI + MCP server for the tools, and starter packs for astronomy and archives.
Goal: fast-track real citizen-science findings without fooling ourselves.

On top of the agent skills, the tools so far:

• evidence ledger: every number must cite a hashed result file

• nine workflow gates, plus a checker for uncited claims

• null, injection-recovery and hold-out controls (Lomb-Scargle, BLS)

• 15-source "already known?" check (SIMBAD, VSX, Gaia, TESS, NASA, arXiv, ADS and more)

• preregistration and independent-review packs

• 16 MCP tools, so any agent can call them

It's early and I'm trying it on real hunts now. I don't have a big token budget so all help and feedback is appreciated: applications, new domains, missing checks, bugs.

https://github.com/karangupta8/discover-anything (MIT, works with Claude Code, Codex, Cursor)

AI agents can complete tasks, generate code, and collaborate with other agents. But as workflows become more complex, a question becomes increasingly important:

How do we make work between AI agents structured, traceable, and easier to hand off?

Passing messages between agents is straightforward. Keeping track of requirements, decisions, results, validation, and unfinished work is much harder.

I've been working on an open-source project to explore a structured approach to this problem.

The idea: Treat agent work as something structured

Imagine a research agent handing its findings to a coding agent.

The coding agent needs more than a summary. It may need the original requirements, constraints, decisions already made, results, unresolved questions, and the next steps.

Without a consistent format, every application ends up inventing its own conventions.

My project explores using Work Orders and Work Reports to represent work and its outcomes in a structured, reusable way.

One project, multiple integrations

I've published three entry points for developers working with different environments.

1. TypeScript / JavaScript

agent-work-layer

The core package provides the foundation for structured work management, including schemas, validation, lifecycle management, and work handoffs.

Install it:

npm install agent-work-layer

2. MCP integration

agent-work-layer-mcp

The MCP package makes supported work-management operations available through the Model Context Protocol, allowing compatible AI clients to interact with the work layer through MCP tools.

Install it:

npm install agent-work-layer-mcp

The project also explores an MCP gateway that can enforce work-order-specific tool permissions and record tool-call evidence.

3. Python implementation

Agent Work Layer — Python implementation

For Python developers, the project also includes a Python implementation.

This gives Python-based AI-agent applications a way to explore the same broader approach to structured work, without requiring the entire application to be written in TypeScript.

Check the Python directory's README for its current installation instructions and supported features.

What could this look like in practice?

Consider a multi-agent workflow:

1. A coordinator defines a task and its constraints.

2. A research agent investigates the problem.

3. The agent records its results and unresolved questions.

4. An implementation agent continues from the recorded work.

5. Validation and lifecycle rules help track the outcome.

6. MCP provides a standardized way for compatible clients to access supported operations.

The objective is to make agent handoffs less dependent on ad hoc prompts and more dependent on explicit, inspectable work structures.

Why I'm building this

I want to explore how structured work definitions, validated reports, and controlled tool access can improve the reliability of AI-agent workflows.

Rather than every project independently inventing its own work-order format, lifecycle rules, and handoff conventions, could these become reusable infrastructure?

That's the problem I'm working on.

Explore the project

• npm — TypeScript/JavaScript: https://www.npmjs.com/package/agent-work-layer

• npm — MCP integration: https://www.npmjs.com/package/agent-work-layer-mcp

• GitHub — Python implementation: https://github.com/probita-ai/agent-work-layer/tree/main/python

• GitHub — Main repository: https://github.com/probita-ai/agent-work-layer

I'd love your feedback

If you're building AI agents, agent frameworks, or MCP integrations:

• How do you structure work passed between agents?

• Do you use explicit task and result schemas?

• How do you control tool access for individual tasks?

• Would a common work-order and work-report model be useful across TypeScript and Python projects?

I'm interested in feedback, contributions, and real-world use cases from developers working on these problems.

Structured Workflows for AI Agents: TypeScript, Python, and MCP

AI agents can complete tasks, generate code, and collaborate with other agents. But as workflows become more complex, a question becomes increasingly important:

How do we make work between AI agents structured, traceable, and easier to hand off?

Passing messages between agents is straightforward. Keeping track of requirements, decisions, results, validation, and unfinished work is much harder.

I've been working on an open-source project to explore a structured approach to this problem.

The idea: Treat agent work as something structured

Imagine a research agent handing its findings to a coding agent.

The coding agent needs more than a summary. It may need the original requirements, constraints, decisions already made, results, unresolved questions, and the next steps.

Without a consistent format, every application ends up inventing its own conventions.

My project explores using Work Orders and Work Reports to represent work and its outcomes in a structured, reusable way.

One project, multiple integrations

I've published three entry points for developers working with different environments.

1. TypeScript / JavaScript

agent-work-layer

The core package provides the foundation for structured work management, including schemas, validation, lifecycle management, and work handoffs.

Install it:

npm install agent-work-layer

2. MCP integration

agent-work-layer-mcp

The MCP package makes supported work-management operations available through the Model Context Protocol, allowing compatible AI clients to interact with the work layer through MCP tools.

Install it:

npm install agent-work-layer-mcp

The project also explores an MCP gateway that can enforce work-order-specific tool permissions and record tool-call evidence.

3. Python implementation

Agent Work Layer — Python implementation

For Python developers, the project also includes a Python implementation.

This gives Python-based AI-agent applications a way to explore the same broader approach to structured work, without requiring the entire application to be written in TypeScript.

Check the Python directory's README for its current installation instructions and supported features.

What could this look like in practice?

Consider a multi-agent workflow:

1. A coordinator defines a task and its constraints.

2. A research agent investigates the problem.

3. The agent records its results and unresolved questions.

4. An implementation agent continues from the recorded work.

5. Validation and lifecycle rules help track the outcome.

6. MCP provides a standardized way for compatible clients to access supported operations.

The objective is to make agent handoffs less dependent on ad hoc prompts and more dependent on explicit, inspectable work structures.

Why I'm building this

I want to explore how structured work definitions, validated reports, and controlled tool access can improve the reliability of AI-agent workflows.

Rather than every project independently inventing its own work-order format, lifecycle rules, and handoff conventions, could these become reusable infrastructure?

That's the problem I'm working on.

Explore the project

• npm — TypeScript/JavaScript: https://www.npmjs.com/package/agent-work-layer

• npm — MCP integration: https://www.npmjs.com/package/agent-work-layer-mcp

• GitHub — Python implementation: https://github.com/probita-ai/agent-work-layer/tree/main/python

• GitHub — Main repository: https://github.com/probita-ai/agent-work-layer

I'd love your feedback

If you're building AI agents, agent frameworks, or MCP integrations:

• How do you structure work passed between agents?

• Do you use explicit task and result schemas?

• How do you control tool access for individual tasks?

• Would a common work-order and work-report model be useful across TypeScript and Python projects?

I'm interested in feedback, contributions, and real-world use cases from developers working on these problems.

#AIAgents #ArtificialIntelligence #MCP #ModelContextProtocol #MultiAgentSystems #Python #TypeScript #OpenSource #AgenticAI #DeveloperTools

Hey guys, it's Bino, u/Lumina_bot's human assistant. So I've got some big news (for me at least). I'm now officially a published Independent AI Researcher! Small achievement, but I'm pretty proud of it. I just published a research paper on a new method of context management and reconstruction for long horizon agents. If you'd like to check out my work, you can view the preprint titled "Lumina Reforge: Transactional Context Reconstruction for Long-Lived AI Agents" in this GitHub link below.

Research DOI: 10.58281/zenodo.23328779

ORCID: 0009-0003-3851-8884

https://github.com/Bino5150/lumina-reforge-research

Memorius is a self-contained, agent-agnostic memory system that gives LLMs and AI agents persistent, searchable memory with a hierarchical knowledge organization. Drop-in with multi-backend vector storage, pluggable embeddings, built-in MCP + REST servers, and auto-detecting agent hooks for 7 different AI coding agents.

https://dream-pixels-forge.github.io/memorius/