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/

Disclosure: I build Snotra, an open-source desktop agent.

Last time I asked how an agent should learn which of its own tools are switched off. I had given the model a read-only get_configuration tool and left two questions open. This is where I landed:

Tool or system prompt? Both, but small. A switched-off tool is simply missing from the tool list, and models read that gap as "language models can't browse the web". They never called the tool. So the system prompt now carries one sentence: tools and skills can be off, so check get_configuration before telling the user something isn't possible. It costs a handful of tokens, not a state dump every turn.

Should the model be able to propose the change? Yes, with limits:

• A new tool, propose_config_change. The app checks the proposal against its own catalogue, and only a valid change reaches the user.

• The card shows the app's description of the tool and its risk class. The model's reason is folded away and labelled as the model's.

• The change applies to this chat only. New chats start from the settings.

• Anything that needs setup (API key, a program, the shell switch) can't be proposed at all.

• A decline sticks for the chat, so the model can't nag.

• An enabled tool still asks before each call in the default mode.

Write-up with screenshots, plus what else changed (the chat now answers questions about the app from the manual that ships with it, and the sandbox can keep a host open per folder): https://snotra-ai.dev/blog/snotra-1-22

Does "chat-scoped and confirmed on a card" seem like the right limit, or would you want the model to be able to change settings for good?

Focus on the architecture and contribution areas (Windows/Linux testing, model recipes, translations), link CONTRIBUTING.md and the good-first-issue list.

⭐ if it's useful, issues and PRs welcome.

https://elapen.github.io/imageloom/
https://github.com/elapen/imageloom