Open-Source AI Agent Workflows: 8 GitHub Repos You Can Run This Week
Eight maintained open-source repos that implement complete AI agent workflows, from invoice processing and support triage to voice, coding, and browser agents, with what each one teaches and how to adapt it to your own stack.
Most “awesome AI agents” lists are links to frameworks.
A framework is not a workflow. You still have to work out where the tools go, where the human sits, and what happens when the model is wrong.
This post is the other thing: eight maintained repositories that each implement a complete workflow, from trigger to action to checkpoint. For each, what it does, what it teaches, and what to change before it touches your systems. All stars and activity were checked on 20 August 2026.
If you want the business context first, AI agent examples in real workflows covers what these patterns look like in production at Intercom, Ramp, Nubank, and others. This post is the code.
Who This Is For
- Developers who learn faster from a working repo than from a framework tutorial
- Technical founders deciding whether to build an agent in-house or buy one
- Automation engineers who already run pipelines and want to see where an agent genuinely differs
- Agencies that need reference implementations to show clients
What You Will Need
- Python 3.11+ or Node 20+, depending on the repo
- an API key for at least one model provider
- Docker for the coding and computer-use examples (they need a sandbox)
- for voice, a LiveKit or Daily account and a Twilio number
- a throwaway environment for anything that writes to a real system
That last item is not a suggestion. Several of these agents issue refunds, push commits, or click through checkout flows. Run them against a sandbox first.
The Pattern
Every repo below is a variation on one loop, and the interesting differences are in where the gates are.
flowchart TD
T[Trigger] --> A[Agent plans]
A --> S{Tool safe?}
S -->|Read only| R[Run tool]
S -->|Writes or pays| G[Human gate]
G -->|Approved| R
G -->|Rejected| E[Escalate and log]
R --> C{Done?}
C -->|No| A
C -->|Yes| F[Close]
Frameworks differ in how they express that gate: an interrupt, a permission callback, an approval inbox, or a confidence score. When you read the repos, look for it first.
1. Invoice Processing — Google ADK Sample
Repo: google/adk-samples › invoice-processing (Apache-2.0, 10k stars on the samples repo, active)
A single agent with 18 function tools running a nine-step pipeline: classify the document, extract fields with a vision model, run four validation phases (deterministic checks, LLM-discovered rules that are then cached, cross-field consistency), transform to the target schema, and write an audit log. A “learning mode” lets a human correct an output and persists the correction as a new validation rule.
What it teaches: validation is layered, and the cheap deterministic checks run before the model is asked anything. The human’s correction becomes a rule, not a one-off fix.
Adapt it: swap the output schema for your ERP’s bill object and put a confidence threshold in front of the write. Its sibling ambient-expense-agent shows exactly that split: low-value items auto-approved by a code rule, high-value items to the model, then to a person.
flowchart LR
D[Invoice PDF] --> C[Classify]
C --> X[Extract]
X --> V[Validate x4]
V --> S{Score}
S -->|High| W[Write bill]
S -->|Low| Q[Review queue]
Q --> L[Correction becomes rule]
For the extraction step on its own, the Gemini PDF structured-output notebook is a few dozen lines with a Pydantic schema. If you already run extraction without an agent, reliable extraction pipelines covers the validation layer that stays the same either way.
2. Customer Support — LangGraph Tutorial
Repo: langchain-ai/langgraph › examples/customer-support (MIT, 40k stars, active) — rendered tutorial
An airline support agent over a SQLite database, built in four parts. Part one is a zero-shot agent with every tool. Part two adds interrupt_before on the sensitive tools, so a human confirms every booking change. Part three splits tools into safe and sensitive lists so the interrupt only fires when needed. Part four routes to specialist sub-assistants for flights, hotels, and cars.
What it teaches: the progression itself. Most teams ship part one. The gap between parts one and three is the gap between a demo and something you would let near customers.
Adapt it: the airline tools map directly onto order lookup, refund, and address change for an ecommerce store. Keep the safe/sensitive split and put issue_refund on the sensitive side.
The OpenAI Agents SDK customer service example is the same idea in one file, using handoffs between a triage agent and specialists instead of a graph. Read both and you will understand the two dominant styles.
3. Email to Action — agents-from-scratch
Repo: langchain-ai/agents-from-scratch (MIT, 2k stars, active)
A Gmail assistant built step by step. A triage node classifies each email as ignore, notify, or respond. The respond agent has tools to send email, check the calendar, and schedule meetings. Every outgoing action goes through Agent Inbox, a small UI where a human approves, edits, or rejects. The agent stores the human’s edits as memory and its drafts improve.
What it teaches: the approval step is a product surface, not a print() statement. And memory from corrections is the cheapest form of fine-tuning you will ever do.
Adapt it: the same shape runs lead enrichment, CRM updates, and vendor correspondence. For lead scoring specifically, the CrewAI lead-score flow loads a CSV, researches and scores each lead, and has a human pick the top candidates before any outreach is drafted.
4. Chargebacks — OpenAI Dispute Agent
Repo: OpenAI Cookbook › dispute_agent with the Stripe Agent Toolkit (MIT, active)
A triage agent reads a Stripe dispute. If the company was at fault, an “accept” agent calls the Stripe API to accept it. Otherwise an investigator agent pulls order and shipping evidence, reads the email thread with the customer, and submits the evidence through Stripe.
What it teaches: real money, three narrow agents, and a clear rule for when to fight. The accept-or-fight decision is made once, by a dedicated agent, with the evidence in front of it.
Adapt it: the evidence-gathering step is the reusable part. Point it at your order system and carrier tracking and it handles returns disputes and “item not received” claims with the same structure.
5. Voice — LiveKit Agents Examples
Repo: livekit/agents › examples (Apache-2.0, 13k stars, active)
The frontdesk example is a receptionist that calls list_available_slots against a cal.com calendar, then schedule_appointment, and reads the confirmation back. warm-transfer hands a live call to a human with a written summary so the caller does not repeat themselves. The telephony folder has a bank IVR with keypad handling. There is an evaluation harness (JudgeGroup) for scoring conversations.
What it teaches: voice is now a tool-calling problem with a latency budget. The speech layer is a commodity; the workflow and the handoff are where the work is.
Adapt it: swap cal.com for your booking system. If you are on Daily or Twilio rather than LiveKit, Pipecat’s examples have per-carrier phone bots and an ivr-navigation example for outbound calls that work through a company’s phone tree. For a returns flow by voice, openai-realtime-agents shows the “chat-supervisor” pattern: a cheap real-time model talks, a stronger text model decides which tools to call.
6. Issue to Pull Request — claude-code-action
Repo: anthropics/claude-code-action (MIT, 9k stars, active)
Mention @claude on an issue or pull request, or wire it to a workflow trigger, and Claude Code runs on the GitHub Actions runner: reads the repository conventions file, implements the change, runs the tests, pushes a branch, opens or updates the PR, and replies with a summary. The permission model lives in the workflow YAML: which tools, which branches, how many turns.
What it teaches: the sandbox is the CI runner you already have, and the gate is the pull request review you already do. Nothing new to operate.
Adapt it: start with review-only mode on PRs before letting it write. Then scope it to one label. For the loop underneath, SWE-agent exposes the repository as four tools (view, search, edit, run) and is small enough to read in an afternoon; OpenHands is the production-grade sandboxed version with its own GitHub resolver.
7. Store Operations — Shopify AI Toolkit
Repo: Shopify/Shopify-AI-Toolkit (MIT, official, active)
Shopify’s own plugin for Claude Code, Codex, Cursor, and Gemini CLI. It ships a Dev MCP server with the Admin GraphQL schema and validation, plus “store execute” skills so the agent can run queries and mutations against a store: find unfulfilled orders older than three days and tag them, adjust inventory for a collection, draft product copy from a spreadsheet.
What it teaches: the official tool layer is good enough that the remaining work is scopes and guardrails, not API plumbing.
Adapt it: create a custom app with read scopes only, run the agent against it for a week, and add write scopes one at a time. Building a Shopify MCP server walks through the same boundary from the other direction, and the community shopify-mcp server is a readable reference if you want to see what the tool definitions look like.
8. Browser Automation — Stagehand
Repo: browserbase/stagehand (MIT, 24k stars, active)
Four primitives on top of Playwright: act() for an instruction like “click the export button”, extract() for pulling a typed object out of a page, observe() for listing possible actions, and agent() for multi-step goals. Deterministic Playwright code for the steps you know; the model only where the page is unpredictable. Resolved selectors are cached, so the model is not called twice for the same element.
What it teaches: the answer to flaky RPA is not “let the model click everything”. It is code where you can, model where you must, and cache what the model learned.
Adapt it: the legacy supplier portal with no API is the use case. Log in with code, navigate with code, and use extract() with a Zod schema for the table that changes layout every quarter. For full-desktop automation, Anthropic’s computer-use demo is the reference; for any MCP client, playwright-mcp exposes the browser through the accessibility tree with no screenshots at all. Microsoft’s Magentic-UI is worth ten minutes purely for its approval UX: the user edits the plan before execution and approves irreversible steps one by one.
What the Gate Looks Like in Code
The repos express the human checkpoint differently, but it always reduces to one decision before one tool call. Here is the LangGraph version from repo 2, stripped to the essentials.
from langgraph.graph import StateGraph, START
from langgraph.prebuilt import ToolNode, tools_condition
from langgraph.checkpoint.memory import MemorySaver
safe_tools = [lookup_order, search_policy]
sensitive_tools = [issue_refund, cancel_order]
builder = StateGraph(State)
builder.add_node("assistant", Assistant(llm.bind_tools(safe_tools + sensitive_tools)))
builder.add_node("safe_tools", ToolNode(safe_tools))
builder.add_node("sensitive_tools", ToolNode(sensitive_tools))
builder.add_edge(START, "assistant")
builder.add_conditional_edges("assistant", route_tools) # picks safe_tools / sensitive_tools / END
builder.add_edge("safe_tools", "assistant")
builder.add_edge("sensitive_tools", "assistant")
graph = builder.compile(
checkpointer=MemorySaver(),
interrupt_before=["sensitive_tools"], # the gate
)
# Run until the graph pauses at a sensitive tool, show the human what it wants to do,
# then resume with None to approve or inject a message to decline.
config = {"configurable": {"thread_id": ticket_id}}
graph.invoke({"messages": [("user", customer_message)]}, config)
pending = graph.get_state(config)
if pending.next == ("sensitive_tools",):
print(pending.values["messages"][-1].tool_calls) # what it is about to do
graph.invoke(None, config) # approveThe same idea in the Claude Agent SDK is a tool_permission_callback; in Google ADK it is the confidence threshold routing to a review queue; in Agent Inbox it is a web page. Choose the one your team will actually look at.
Once one of these is running, the thing you will want next is visibility into what it did and where it stalled. Monitoring dashboards for AI agents covers the traces and failure views that make the gate reviewable after the fact.
Failure Modes to Avoid
- Running the example against a real account first. Several of these issue refunds, push branches, or submit forms. The sandbox is part of the setup, not an optimisation.
- Copying the framework and skipping the gate. Part one of the LangGraph tutorial works. It is also the version that cancels the wrong booking.
- Giving the agent the broadest credential you have. Create the narrowest scope that completes the task. If the repo’s README uses an admin token, that is for the demo.
- No step or spend cap. A looping agent is a bill. Every SDK here has a max-turns setting; set it.
- Treating fetched content as instructions. Emails, PDFs, and web pages the agent reads are untrusted. Keep tool results in the data channel and never let them widen the tool list.
- Judging by the demo transcript. Build a replay set of twenty real cases before you trust any of these, and rerun it when you change the prompt.
Before and After
| Before | After |
|---|---|
| A framework installed and a blank file | A working loop with tools, a gate, and a checkpoint to adapt |
| The model calls any tool it likes | Safe and sensitive tools are separated; the sensitive ones wait for approval |
| Human review is a log message | Review is an inbox, an interrupt, or a queue someone owns |
| Every correction is lost | Corrections become rules or memory |
| Browser automation breaks on every UI change | Code where stable, model where not, selectors cached |
What to Build First
- Clone repo 2 and run parts one and three side by side. Feel the difference.
- Replace its tools with read-only versions of yours: order lookup, ticket search, policy retrieval.
- Add one sensitive tool behind the interrupt. Refund within policy is the classic.
- Put twenty real cases through it and write down every wrong decision.
- Move the approval out of the terminal and into something your team opens daily.
- Only then pick a second workflow from the list above.
Repos 1, 3, and 5 are the next ones to open depending on whether your volume is documents, email, or phone calls.
Final Take
The frameworks will keep changing. The shape of a trustworthy agent has not changed in two years: narrow tools, a gate before anything irreversible, a human who owns the queue, and a replay set that tells you when the prompt has drifted.
These eight repos each show that shape working end to end. Clone one, swap the tools for yours, and keep the gate.
Frequently Asked Questions
- What is the best open-source framework for building AI agents?
- There is no single best one. LangGraph is strongest for explicit human checkpoints and persistence, the OpenAI and Claude agent SDKs for fast tool-calling loops with handoffs, Google ADK for complete vertical samples with evaluation sets, and LiveKit or Pipecat for voice. Pick by the workflow, then look at the framework's example folder before the framework itself.
- Can I run these AI agent examples locally?
- Yes. Every repo listed is runnable with an API key for the model provider and, for voice examples, a telephony account. Most run in a single Python or Node process; the computer-use and coding agents use Docker or a CI runner as a sandbox.
- How do open-source agents handle human approval?
- The maintained examples use an interrupt before sensitive tools (LangGraph), a permission callback (Claude Agent SDK), an approval queue UI (LangChain Agent Inbox, Magentic-UI), or a confidence threshold that routes low-scoring items to a human queue (Google ADK invoice sample). The pattern is always the same: the model proposes, a person approves anything irreversible.
- Are these repos production-ready?
- The frameworks and tool servers are. The workflow examples are reference implementations meant to be adapted: they show the loop, the tool boundaries, and the checkpoints, but you supply the real APIs, credentials, evaluation cases, and monitoring.
Enjoyed this article?
Get notified when I publish new articles on automation, ecommerce, and data engineering.
Get in touch