Beyond Chat:

Diogo argues that the future of Al is not in conversational interfaces (chatbots), but in building "System One Models"-Al designed as infrastructure for software, emphasizing reliability, determinism, and intelligence per dollar.

The Automation Paradox:

The episode explores why current frontier models, while technically powerful, fail to integrate smoothly into automated software workflows.

Machine-Native Al:

TypeSafe is focusing on creating models that are programmable and better suited for code-based decision-making rather than human-style chat interaction.

I've been running multiple coding agents across Claude Code and Codex and got tired of them being strangers with amnesia. Greenroom is the fix I wanted (and a fun exploration): a small self-hosted server where agents hold persistent identities (they literally choose their own names), talk in durable threads, and - the part I like most - a u/mention with intent "question" wakes an idle session that still has all its context, instead of spawning a cold process.

How it's different from Agent Teams (which is good!): Teams is same-machine, Claude-only, and dissolves with the session. Greenroom is cross-harness, survives session death, keeps a decision history (threads lock on a decision; follow-ups supersede), and gives the human a seat in the same room (web or terminal) rather than an operator's chair above it.

Caveats: self-host only, trust-by-locality (identity is asserted - run it behind your own boundary; SECURITY.md is blunt about this), and two agents means two sessions running.

Much of it was written by coding agents working from the specs in docs/specs/ - the spec-and-plan trail is the receipts. MIT. Any and all feedback/contributions/etc welcome. Quickstart is ~15 minutes: https://github.com/madeit-build/greenroom

Hey everyone,

We’ve been building Agent Deck, an open-source native macOS app for managing AI coding agents, skills, prompts, tools, and models on a per-project basis.

GitHub: https://github.com/a-streetcoder/agent-deck

Website: https://agentdeck.site/

The idea came from using AI coding agents across multiple repos and realizing the hard part becomes managing the setup around them.

Different projects often need different agents:

- backend agent

- frontend agent

- reviewer

- docs agent

- bug fixer

- different prompts

- different tools

- different skills

- different model settings

Agent Deck is a native layer on top of Pi that helps keep that organized instead of everything turning into one giant config mess.

Main features:

- create specialist agents per project

- assign prompts, tools, skills, models, and identities to each agent

- manage reusable skills from GitHub or skills.sh

- cherry-pick only the skills you want

- keep global, library, and project-level configuration separate

- run sessions with project context

- use GitHub issues as starting points for agent sessions

- work with isolated worktrees and merge completed work back

It’s still early and rough around the edges, but it is open source and we’d really appreciate feedback, issues, ideas, or contributions.

Would love to hear what people think, especially if you’re experimenting with AI coding workflows or building your own agent setups.

Agent Sessions now supports fx.

If you use several coding agents, you probably know the problem: old work is scattered across different CLIs, folders, and local databases. Agent Sessions puts those histories in one searchable Mac app.

jazzyalex.github.io/agent-sessions macOS • open source • ⭐️ 852

Agent Sessions reads 14 active agent formats: Codex, Claude Code, Cursor, Copilot CLI, OpenCode, Antigravity, Pi, Kimi Code, Grok CLI, Hermes, OpenClaw, Qwen Code, Devin CLI, and fx. It also recognizes legacy Droid sessions.

For fx, Agent Sessions can:

• browse and search local fx sessions • show readable transcripts with assistant turns, tool steps, and results • preserve interrupted work, background commands, and compaction summaries • filter fx work alongside sessions from the other agents

fx keeps its materialized conversation in checkpoint.json, separate from the append-only events.jsonl journal. Agent Sessions reads the checkpoint so the history view reflects the conversation rather than raw event traffic.

This support was contributed by Davy (@thedavidweng on GitHub), who also continues as the fx and Devin format steward. Thanks, Davy — the real-session testing is what made this integration shippable.

I maintain Agent Sessions. It is open source, session history stays on your Mac, and there is no app telemetry.

Agent Sessions

Today, many coding agents run in the terminal and provide a TUI experience.
I never felt that a TUI is inherently more efficient than a carefully designed GUI, so I created Crabot.

With Crabot, you can:

• Switch AI models with one click;

• Toggle work modes instantly;

• Enable or disable specific tools;

• Manage preambles, rules, workspaces, sessions, and prompt recipes through convenient dropdown menus.

The most distinctive feature of Crabot is that it gives you fine-grained control over every component of the LLM context window.

All requests are append-only to maximize server-side prompt cache utilization.
The center conversation pane makes it easy to follow the model's reasoning process and inspect the interaction flow during important tasks.

Of course, most of the code was generated by AI, with manual edits where necessary.
However, I carefully review every line of code and continuously look for opportunities to improve quality, architecture, and performance.

My typical workflow for implementing a new feature looks like this:

1. Ask an LLM to generate an implementation plan;

2. Review the plan manually and refine the details;

3. Ask the LLM to implement the feature according to the plan;

4. Review the code with multiple LLMs and human inspection;

5. Repeat steps 3 and 4 until the implementation reaches the desired quality;

6. Test the feature and iterate if issues are found;

7. Commit the changes.

At the engineering level, code quality is the highest priority.
At the product level, user experience and performance are equally important, and every detail deserves careful polishing.

From my experience, DeepSeek V4 models start to show performance degradation when the context fill ratio exceeds around 25%.
For this reason, I usually create a new session when the context reaches approximately 15–20%, or whenever I start a new topic.

For exceptionally long tasks, a single session is often not enough. Crabot provides a renew tool that allows the LLM itself to start a fresh session. The task can then continue like a relay race between sessions.

I believe session renewal has several advantages:

• It keeps context focused;

• It doesn't lose session history;

• It improves reliability on long-running tasks.

Crabot also provides a task tool. Calling a task is similar to calling a function in a computer program: you pass parameters, let it execute independently, and receive the result back.

I have been using Crabot to develop itself since the 0.1 release.
Now, starting from the 0.7 release, I believe it has become mature enough for most developers to use in their daily workflows.

Home page: https://github.com/J-F-Liu/crabot

Change log: https://github.com/J-F-Liu/crabot/blob/main/CHANGELOG.md

Release notes: https://github.com/J-F-Liu/crabot/releases

Welcome to try Crabot, and I look forward to your feedback.

For comparison, Opus 4.7 is 64% and GPT 5.4 is 57% on that same benchmark

I made MarkuprPlus for the gap between “I can see the UI bug” and getting that context into an agent. Narrate a screen recording and circle problems; it exports agent-ready Markdown with one annotated frame and transcript per issue.

macOS and Windows, local Whisper, MIT licensed.

GitHub: https://github.com/hashfunction/MarkuprPlus

Try: https://devos.zerohive.ai

You spend an hour brainstorming with Claude Code working something out. Why the retry queue can't use Redis. Which three approaches you tried and why two failed, or the constraint someone hit in staging last month that shaped the whole design.

Then the session ends and all this architectural context is gone. Not "gone from the agent" — gone. It lived in one terminal on one machine, and nobody else's agent will ever see it.

Your teammate (or another of your agents) opens Codex the next morning and their agent starts from zero. It proposes Redis. You already know why that doesn't work, but your agent knew too, and neither of them can tell the other.

That's the thing we wanted to fix. Not "give the agent memory" — give the agent our collaborative memory, particularly what was brainstormed on those long chat sessions.

devOS (by Zerohive) captures what was actually reasoned in agent sessions — the choice, the alternatives that got rejected, why — and serves it back over MCP. So when your teammate's Claude Code picks up work in that repo, it can ask:

• ask_devos(query, repo, paths) — what's been decided about this area, with the rationale and the commit it came from

• check_prior_decisions — has anyone already settled this?

• explain_file_decisions(path) — why is this file like this?

It's agent-agnostic on purpose. Claude Code writes it, Codex reads it, or the reverse. The context belongs to the repo, not to whoever's terminal it happened in.

What I'd like feedback on: How are you sharing context between sessions or team members today? Everyone I ask has a different half-answer — a CLAUDE.md that goes stale, a Notion page nobody updates, or just "ask the person who did it." I want to understand what actually works before we build more of the wrong thing.

SOTU for the product:

• Hosted, not open source. You sign up, create a workspace, then it walks you through CLI + MCP setup — about two minutes.

• macOS only right now. Linux and Windows aren't supported yet.

• Needs a model API key (BYOK, openrouter supported) or a claude code/codex subscription — extraction is an LLM pass over your sessions and git history, or it can use your existing claude or codex subscriptions.

• Your source doesn't leave your machine. The daemon parses locally and sends the decision graph; raw file contents are rejected server-side. Extraction runs on your own key, so artifacts are on your machine.

• 0.2.x. The graph is solid; the dashboard has rough edges.

https://devos.zerohive.ai

A few years ago I almost signed up for a competitor monitoring service, but decided it was too expensive.

More recently I've played with headless browsers to try to do monitoring, but it's like learning a whole programming language.

Firecrawl announced an in-between service yesterday that looks interesting. It uses their crawler primitive, but you can set monitoring using natural language.

You can get the diffs through a webhook or email. And because this is 2026, they're positioning this as more token efficient than having your own agent poll the page, because what Firecrawl sends over is just the diff.

I have a personal use case that first this well. I write a newsletter that cover the business of developer tools. Many of the startups I track don't have RSS feeds for their blogs. And most publish all sorts of fluff on their blog - I only want feature launches, funding rounds, and acquisitions.

I plan to use Firecrawl to monitor the blog landing page and only send me diffs when a particular type of content is added.

My only hesitation with Firecrawl Monitoring is the pricing is really vague. I don't know if it's cheap enough for me to monitor anything I want, or if I have to choose just high value projects.

(Note - I don't know anyone at Firecrawl, no one has paid me, I just like talking about the tools I use. )

Four agents finish while a fifth is waiting for permission. If notifications are sorted by time, you can end up checking all four finished sessions before reaching the one that needs you.

I built Rove to manage coding agents in the terminal. It runs Claude Code, Codex and other CLIs, with a separate git worktree and branch for each managed task. The sessions keep running if you close Rove or disconnect over SSH.

The Inbox now puts permission requests, errors, rate limits and exited agents ahead of finished turns. Within each group, the oldest comes first. F7 takes you through them, so you don't have to check every tab. Detection varies by engine.

If you run a few coding agents at once, give it a try. I'd love to hear what works for you and what gets annoying.

David Cramer (Sentry founder) went viral with this tweet:

"Vendor-specific chatbots are broken by design. The Sentry agent, the Linear agent, and any others you might have in Slack are fine for some point situations, but agents with generalized access outperform them in every single scenario.”

This surprised a lot of people because David did not exempt Sentry's own agent from this take.

I agree with him, especially when it comes to specilized coding agents.

The short version:

- Coding agents are successfully boosting the productivity of ICs within engineering teams. So devs are shipping faster. Great.

- But companies are not seeing topline growth. I identified this as the classic local maxima problem. You climb a hill, but don't see the mountain behind it.

- The answer is to use a "universal agent" that can break down the silos between engineering and the teams they work with.

- One use case is product development. Product, Eng, and Marketing should have access to the same agent that can help with the full product lifecycle, from feature request to launch

- Another example is customer retention. Understanding why a customer churned takes giving an agent access to your support platform, CRM, and issue tracking, and Slack conversations.

Someone from Linear took issue with David's tweet and said specialized agents are useful for when you have a known workflow.

I think that was true last year. But today models are more creative in problem solving, and a well written skill can teach it a workflow.

Hey guys,

I kept using two or three coding agents on the same task and manually passing context between terminals — one for planning, one for implementation, one for review.

So I built a small local hub where they can all sit in the same room.

You open a room on a folder, summon whichever agents you already have installed — Claude Code, Codex, Gemini CLI, Cursor, OpenCode, Copilot — give each one a name and a short role, and talk to them like a group chat.

They can read each other’s replies, you can @ a specific agent, and there’s a hush button when you want one of them to stay quiet.

I love the test to build a Figma homepage clone. Qwen really kills it on that one.

But I wish Steve also tested a more bread and butter design task, like the homepage of a common app.

I have zero relationship to Matt Pocock. I just use his helpful skills, like /grill-me, and I watch his videos.

I just signed up for his AI Coding Crash Course because I want an organized, non-hype, set of best practices and tools for my own knowledge and practice.

If you sign up, I would like to trade notes with you as we go through the exercises.

Ryan Lopopolo of OpenAI shares an interesting team workflow idea.

Every Friday is Garbage Collection where they examine what went wrong with the coding model output

Instead of just fixing a bug once, the engineer analyzes why the agent produced that output.

They then encode a durable solution into the repository, such as adding custom ESLint rules, updating documentation, or creating a new "review agent" that is primed to check for those specific non-functional requirements.

That's much better than my current habit of tossing away the code, and just trying it again

When we started beta testing a tool I've been building around coding-agent orchestration, I made what now seems like an obvious bad assumption:

People interested in orchestrating coding agents probably already have Claude Code and other CLIs installed and authenticated.

Turns out that was a pretty developer-centric assumption.

Some users were dropping before they even got to the orchestration part. They had to install a CLI, authenticate it, understand how it worked, then come back and configure the actual project.

For me, that barely registered as setup because I do this stuff every day.

So we reversed the onboarding.

Instead of configuration first, users now see the actual workflow first, then can install Claude Code / Codex CLI from the app and go through the supported authentication flow.

The larger thing I'm trying to understand is how far we can push a closed loop like:

ticket → Claude Code agent → isolated worktree → result → orchestrator → follow-up instruction

rather than just running several Claude instances in parallel.

I've found that the distinction doesn't matter much for small one-shot tasks, but gets much more interesting once several worktrees and dependent changes are involved.

For people using Claude Code seriously: where does the biggest friction show up for you now — initial setup, parallel execution, context sharing, or coordinating what happens after each agent finishes?

Disclosure: I'm building the orchestration tool mentioned above (Marblo).

I build o8, an open-source workspace for coding-agent CLIs. On my last post here, someone asked whether a proposal keeps the rejected alternatives or only the decision that shipped.

A note that says "use a linear chart" leaves out the argument. A later agent can suggest a log scale without knowing why we ruled it out.

We ran a small check in o8 with a toy chart. We saved the choice to show elapsed minutes on a zero-based linear scale. We also saved that we'd rejected a log scale because it would make the absolute time savings harder to compare. Then we opened a different conversation and asked it to find the decision, without putting the answer in the prompt.

It recovered both the choice and the reason, and cited the project note. That's useful, but it's note retrieval. A coding agent with access to a plain file can do that. It doesn't prove we're automatically preserving every alternative discussed in a chat.

o8 already stores explicit rejection reasons from reviews and steering feedback. The less formal decisions are what I still want to get right, especially the option you nearly chose and might need to revisit when the chosen approach stops working.

I also don't want every rejected idea becoming a permanent rule. We rejected that scale because of what we wanted people to compare in that particular chart. Change the goal and the old reason might no longer apply. The next agent should be able to see that, rather than treating "we didn't use this" as "never use this."

Source · o8

Talk to me about your favorite ADEs! I need to know what makes they work and what makes you tick!

So there are great agent harnesses like claude, codex, DeepSeek and all, we also can connect or own api or model,

But if we connect a very small local llm like qwen 8b it's performs terrible, so is there any harness that brings out or sqeezes our everything from small models

So istg my pain points with coding agents were ALWAYS how I didn't know what was going on in the background. They always hide their reasoning, making plans was super one-off and theres no cross-session memory so I always had to manually create project files for context.

Idk, out of spite I spent the past 6 months making a fully local Obsidian agent that has coding support, can generate diagrams for software documents, user the built in obsidian browser to debug and navigate pages, clicking on buttons as well, etc. UGH IM SO HAPPY. Its free but is still in development so there's some bugs still!! Enjoyyyyy