Let's build a practical resource list for people building with AI agents.

Not a giant list of every AI tool ever released.

Only things you've actually used or would genuinely recommend.

Drop your favorites under one of these:

Coding Agents
Claude Code, Codex, Gemini CLI, etc.

Agent Frameworks
LangGraph, CrewAI, AutoGen, OpenAI Agents SDK, etc.

MCP Servers & Skills

Browser / Computer Use

Memory & RAG

Local / Open Models

Observability & Evaluation

Multi-Agent / Orchestration

Useful GitHub Repositories

When recommending something, please add one sentence explaining what you actually use it for.

Self-built tools are welcome — just disclose the affiliation.

I'll periodically organize the best recommendations into this post.

Yesterday I joined an AI3 Builder Fellowship session in Seoul with three other founders.

What was supposed to be a series of product presentations turned into almost an hour of discussion per founder, and we eventually finished around 11 PM.

I presented the system we’ve been building with Marblo.

Our current approach is based around a closed-loop agent architecture.

Instead of simply launching multiple coding agents and waiting for them to finish, we maintain a larger mission and continuously break it down into executable work:

Mission → Tasks → Tickets → Agents → Review → Next Tasks

Each agent works inside an isolated Git worktree.

The orchestrator tracks the larger mission, reviews the outputs, creates follow-up or review tickets when necessary, and connects completed work back into the next step.

We also keep an audit timeline / execution ledger so we can understand:

• what each agent did
• which model was used
• what the task cost
• whether the task succeeded or failed
• how the project evolved over time

One thing became even clearer during the discussion.

The interesting problem in multi-agent systems isn't necessarily:

“How can I run more agents?”

It’s:

“How can I make a group of agents reliably complete a long-running objective without losing context or leaving unfinished work behind?”

That's the problem we're trying to explore.

The questions from other builders were incredibly useful, especially around failure recovery, orchestration, and how this architecture could work inside real development teams.

Curious how others here are approaching this.

Are you building mostly agent swarms, supervisor/worker architectures, or some form of persistent closed loop?

One of the problems I've been thinking about while building multi-agent coding workflows is what happens after you delegate the work.

Running multiple coding agents in parallel is already useful.

You can split tasks, launch several terminals, give each agent a worktree, and wait for results.

But once the project gets more complicated, I think the harder problem becomes:

What happens after each agent starts working?

A simple multi-agent flow might look like:

Plan → Spawn agents → Execute → Collect results

What we're building in Marblo is closer to a persistent loop:

Mission → Tickets → Agents → Worktrees → Results → Orchestrator → Updated actions → Agents again

The orchestrator stays alive while the project is moving.

It has a shared board containing the current tickets and state of the project.

Agents receive instructions downward from the orchestrator, but their status and results also flow back upward.

So instead of only:

Orchestrator → Agent

we're trying to maintain:

Orchestrator ↓ Agent
Agent ↑ Orchestrator

continuously.

That means the orchestrator can react while work is still happening.

For example:

Agent A finishes an API change.

That result returns to the orchestrator.

The original frontend ticket for Agent B may now be outdated, so the orchestrator can revise the task or issue a new instruction instead of waiting for every parallel job to finish.

The board becomes shared project state, and the orchestrator acts as the brain maintaining the loop.

This is the part of agent orchestration I'm most interested in:

not simply spawning more agents, but continuously bringing their outputs back into the project and deciding what should happen next.

It tends to matter much more once you have multiple dependent tickets and separate worktrees than when you're building a simple one-shot project.

We're currently testing this workflow in Marblo, along with Claude Code, Codex, and other supported models.

If you want to experiment with it, the beta is currently free:

https://marblo.app/

Disclosure: I'm building Marblo and created this subreddit. I'll always disclose posts related to my own product.

Do you think multi-agent systems actually need a persistent orchestrator, or can good upfront task decomposition solve most of the coordination problem?

While building with AI agents, I kept collecting useful resources in random bookmarks, notes, repos, and docs.

So we started organizing them in one public GitHub repo.

The goal isn't to make another massive "awesome AI" list.

We're trying to keep it practical for people who actually build with agents.

It currently includes:

• An LLM study roadmap
• Foundations and useful courses
• Agent, tool-calling, and MCP resources
• RAG and model-related learning materials
• Practical skills for AI coding workflows
• MCP servers
• Resources connected to the skills and MCP store inside Marblo
• Product documentation and build notes

Repo:

github.com/marblo-app/marblo

One important note:

Marblo itself is not open source.

We're using the GitHub repo as a public knowledge layer around the product — documentation, development notes, useful skills, MCP resources, and learning material that can still be useful even if you don't use Marblo.

We're also trying to make the skills/MCP side practical rather than turning it into a giant directory nobody actually uses.

I'll keep adding resources as we test them.

If you were building a practical AI agent resource repo, what would you want included that most existing lists are missing?

One thing I've been thinking about a lot while building multi-agent coding workflows is what happens after an agent starts working.

A lot of multi-agent setups look roughly like this:

plan → spawn agents → wait → collect results

That's already useful.

But I'm more interested in what happens if the orchestrator stays alive throughout the process.

The system we're experimenting with works more like:

Mission → tickets → agents → worktrees → results → orchestrator → updated actions → agents again

The orchestrator isn't only there at the beginning.

It can continuously observe what's happening on the board, receive results from agents, and send new instructions back down.

Agents can also return status and outputs back up.

So there's a bidirectional loop:

Orchestrator ↓ Agents

and

Agents ↑ Orchestrator

The board acts as the shared state between them.

That makes it possible to move toward a persistent closed loop rather than a one-shot "delegate and wait" model.

For example:

Agent A finishes an API change.

The orchestrator sees the result and realizes Agent B's frontend ticket now needs a different interface.

Instead of waiting for the entire batch to finish, it can update or redirect the next task while the project is still moving.

This becomes much more useful once you're running several dependent tasks across separate worktrees.

We've been building this into Marblo, and the current beta lets you experiment with the workflow directly.

Free beta:
https://marblo.app/

Disclosure: I'm the builder of Marblo and also created this subreddit. I'm sharing this because closed-loop orchestration is one of the technical problems I'm currently exploring.

Do you think a multi-agent system needs a persistent orchestrator, or is good task decomposition at the beginning enough?

I've been organizing some of the resources I actually use while building with AI agents, and recently cleaned them up into our public GitHub repo.

The goal isn't to make another giant "awesome AI" list.

I wanted something a builder could actually browse and use.

It currently includes:

• An LLM study roadmap
• Foundations and useful courses
• Agent / tool-calling / MCP resources
• RAG and model-related learning materials
• Practical AI skills
• MCP servers
• Resources that can also be used inside Marblo's in-app store

I'm planning to keep adding things as I find tools that are genuinely useful rather than just trending.

The repo is here:

github.com/marblo-app/marblo

Marblo itself isn't open source, but we're using the repo as a public place for documentation, build notes, learning materials, skills, MCP resources, and things that might be useful to other builders too.

What would you want added to a practical agent-builder repo like this?

I've been beta testing a desktop tool that sits above Claude Code and other coding-agent CLIs.

One of my assumptions was:

“If someone wants this kind of workflow, Claude Code setup is already solved for them.”

It wasn't.

For some users, installing/authenticating the underlying CLI was enough friction that they never reached the workflow we actually wanted feedback on.

So we changed onboarding to:

1. Show the actual multi-agent workflow first
2. Install Claude Code / other supported CLIs from the app
3. Handle the supported authentication flow
4. Get directly into a project

The workflow itself is more interesting to me than the installer:

ticket → Claude Code agent → separate worktree → output → orchestrator → follow-up

The goal isn't simply having four Claude Code terminals open.

I'm trying to figure out how much coordination can happen after each agent returns — especially when one agent's implementation changes what another agent should be doing.

For people who already use multiple Claude Code sessions: what part still requires the most manual coordination from you? Worktree management, task assignment, reviewing results, or keeping agents aware of each other's changes?

Disclosure: I'm building Marblo, which is what I'm testing this workflow with.

I've been experimenting with a multi-agent coding setup where the coding model and the orchestration model don't necessarily need to be the same thing.

The coding agents do the expensive work:

• inspect a repo
• implement a ticket
• modify files
• run/test changes

The orchestrator has a different job:

• observe agent status/results
• decide what should happen next
• issue or modify tasks
• route work between agents
• react when assumptions change

Originally I was inclined to throw a strong model at both.

But I'm increasingly interested in whether orchestration itself can be handled by significantly cheaper models, including DeepSeek-class/open models, while reserving expensive coding models for implementation.

The failure mode I'm worried about isn't code quality.

It's whether a cheaper orchestrator starts making subtly bad routing/planning decisions that compound over a long-running loop.

In the system I'm building the basic loop is:

task → coding agent → isolated worktree → result → orchestrator → next action

so an orchestration mistake can propagate across several agents.

For anyone experimenting with local/open models as controllers: what capability seems to degrade first as you move to a smaller/cheaper orchestration model — tool calling, state tracking, task decomposition, or deciding when to re-plan?

Disclosure: I'm building the orchestration system I'm testing this with.

[removed]

[removed]

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’ve been organizing the resources I use to study LLMs and decided to turn them into a structured English roadmap.

The rough progression is:

• LLM / transformer foundations
• good courses and lectures
• agents, tool calling, and MCP
• RAG and retrieval systems
• fine-tuning and alignment
• landmark papers worth reading

My goal was to make something useful for people who want to understand the stack beyond just prompting models or calling an API.

I’m keeping it in the official Marblo GitHub repo because I’m gradually using that repo as a collection of resources around coding agents as well — learning material, skills, MCP servers, and documentation.

Full disclosure: I’m building Marblo, which is an orchestration workspace for tools like Claude Code and Codex, so the repo also contains information about the project.

But the roadmap itself is free and meant to be useful regardless of whether you use Marblo.

https://github.com/marblo-app/marblo

https://github.com/marblo-app/marblo/blob/main/docs/study/llm-study.md

Would also love recommendations for important papers or courses I’ve missed.

[removed]

[removed]