DEV Community: Eric Marchand

acpdbg: let the agent sit at the debugger 🐛

Eric Marchand — Sat, 11 Jul 2026 11:08:35 +0000

I had an idea, and it starts from a habit.

LLM agents are genuinely good at static analysis: give them a backtrace and
the source around it, and they usually spot the bad pointer before I do. So what
do I actually do when a native program crashes? I copy the stack trace from the
debugger, paste it into the agent's context, then copy the source of the
functions involved, paste again… I'm the transport layer between two programs
that both live on my machine.

That's the idea: why not let the agent look at the lldb debug data itself —
and even control the debugging?

I already wrote about ACP, the Agent Client Protocol —
the standard that lets any agent talk to any client. Usually the client is an
editor. But nothing says it has to be. A debugger is a perfectly good ACP client
too. So I built one.

acpdbg

acpdbg is an LLDB assistant. When your
C/C++/Rust/Swift program stops — crash, signal, or breakpoint — it captures an
enriched snapshot (backtrace, every frame's live arguments, surrounding source)
and hands it to your coding agent over ACP: GitHub Copilot CLI, Gemini CLI, or
Claude Code through its ACP adapter.

The part I like most: the agent doesn't just read a frozen report. Through a
small MCP tool bridge it can run live debugger commands against the stopped
process — bt, frame variable, p some_expr — to confirm its hypothesis
instead of guessing. And with the opt-in control mode, it gets step_over,
continue_execution, set_breakpoint… so it can debug like a human would:
set a breakpoint, run to it, step, watch the state evolve.

Try it fast

The whole loop works offline with a bundled mock agent, nothing else to install:

pip install acpdbg
git clone https://github.com/phimage/acpdbg && cd acpdbg/samples
make                # builds ./crash with -g
acpdbg -- ./crash   # runs it; on the crash the agent explains

Swap in a real agent for real analysis:

acpdbg --agent copilot -- ./crash

Real output from that command:

acpdbg → copilot (investigating…)

Confirmed live: `s` is 0x0000000000000000 — a NULL pointer — right where
strlen(s) dereferences it.

Root cause: in main, `name` is NULL when the program runs with no arguments,
and describe() hands it to strlen() with no check.

One-line fix: return s ? strlen(s) : 0;

Inside lldb — and inside Xcode

It's also a plain LLDB plugin. Install it once:

acpdbg --install-lldbinit --agent copilot

and every lldb session — including Xcode's debugger console — gets new
commands. Stop anywhere (a crash, a breakpoint, a watchpoint) and just type:

(lldb) ask why is `retry_count` already 3 here?
(lldb) copilot in one sentence, why did this stop?
(lldb) claude what would you change to fix it?

Each installed agent gets its own command, so you can get a second opinion from
another model without touching the config.

It's a try

I don't claim this is the way to debug. It's an experiment: the interesting
part for me is that ACP made it cheap to build — I wrote a client once, and
every ACP-speaking agent works with it, today's and tomorrow's. The same
N×M collapse I liked about the protocol in editors, applied to a debugger.

Code, docs, and caveats: github.com/phimage/acpdbg.
Tell me where it breaks. 🐛

Pipeline, Flow, or Chain? Picking the Right Tool to Wire LLM Calls Together

Eric Marchand — Sat, 11 Jul 2026 09:44:51 +0000

In the previous post I argued that agents are great
planners and DAGs are great executors. This one is the practical follow-up: when
you actually sit down to wire several LLM calls together, what tool do you reach
for?

Because the moment one prompt's output feeds the next, you've built a workflow —
whether you call it that or not.

download transcript → summarize → translate
       (tool)          (LLM)       (LLM)

That tiny pipeline is already the whole problem in miniature: a non-LLM step (fetch a
YouTube transcript), then a model call, then another model call that depends on the
first. Run it as one giant prompt and you lose visibility; split it into steps and you
gain debuggability — at the cost of more calls and more state to manage.

The naming trap

Half the confusion is vocabulary. The same idea ships under a dozen labels:

Name	What it whispers
Chain	sequential, output → input
Pipeline	stages, data flowing through
Flow	branches and conditions
Workflow	general orchestration
Agent workflow	the model also decides

The word sets expectations. "Chain" promises a straight line; "agent workflow"
promises the thing might re-plan on you mid-run. Pick the label that matches how much
autonomy you're actually handing over — calling a deterministic two-step pipeline an
"agent" only invites disappointment.

The real choice: library or orchestrator?

There are two families of tools, and they solve different problems.

LLM-native chaining libraries — LangChain,
LlamaIndex Workflows,
Azure Prompt Flow,
or visual layers like Flowise. These understand
LLM-specific concerns out of the box: prompt templating, passing context between
steps, token budgets, streaming, retries on a flaky model.

General orchestrators — Airflow,
Prefect, AWS Step Functions,
Azure Logic Apps. These treat
each LLM call as just another task in a DAG, and give you the heavyweight reliability
machinery: durable state, scheduling, checkpointing, audit trails, human approval.

The rule of thumb that falls out of the last post:

Few prompts, mostly LLM glue   → chaining library
Many steps, must not fail      → orchestrator (LLM call = one task)
The model decides the path     → agent, with one of the above underneath

When you don't need either

Don't reach for a framework reflexively. If the task is genuinely simple, one
well-crafted prompt (few-shot or chain-of-thought) often beats a three-step pipeline
— fewer calls, less latency, nothing to orchestrate. Chaining earns its keep when
subtasks are distinct enough that isolating them actually improves accuracy and lets
you debug each one independently. The cost is real: every extra hop adds latency, and a
weak early step poisons everything downstream.

A concrete chain

To get a feel for the moving parts I built PromptKit,
a small 4D toolkit where a chain is just named prompts piped together — the YouTube
example above, minus the download step:

var $result:=$runner.newChain().prompt("summarize").prompt("translate").run($transcript)

// $result.text     -> final translated summary
// $result.outputs  -> each step's output, for inspection

Nothing exotic — but writing it made the trade-offs tangible: where state lives, what
happens when step two fails, how you'd add a branch. Which is really the point. You
don't pick the tool by reading the marketing; you pick it by knowing whether your
problem is LLM glue or reliable execution — and most of the time, it's a bit of
both.

My take: "chain vs. workflow vs. agent" is less an architecture question than an
honesty question — how deterministic is your process, really? Name it accordingly,
then pick the lightest tool that survives the day you actually need a retry.

When Agents Become Planners, What Remains of Workflow Orchestration?

Eric Marchand — Sat, 11 Jul 2026 09:44:44 +0000

For years, software automation has been built around a simple idea: define the
process, then execute it. Whether using a script, a workflow engine, or a DAG, the
principle is always the same:

A → B → C → D

The developer knows the steps in advance.

AI agents challenge this model. Instead of defining how to achieve a goal, we
increasingly define what we want and let the agent figure out the steps.

This reminds me of the difference between traditional programming and agentic
programming.

Traditional Programming	Agentic Programming
Define the algorithm	Define the objective
Deterministic execution	Probabilistic execution
Every path is known	Paths emerge dynamically
Optimized for reliability	Optimized for adaptability

When the process is well known, code is often the best solution. When the process is
uncertain, constantly changing, or requires exploration, agents start to shine.

A useful way to think about it is:

Known problem    → Code
Known process    → Workflow
Unknown process  → Agent

This is why some people argue that traditional orchestrators such as
Apache Airflow or
AWS Step Functions are not well suited for
agentic systems. AI agents are fundamentally non-deterministic. They may decide to use
different tools, follow different paths, or even change their plan while executing it.

A static DAG cannot describe every possible future path.

But does that mean workflow orchestration is becoming obsolete?

I don't think so.

Even the most advanced agents still need:

State persistence
Retries
Checkpointing
Human approval
Scheduling
Audit trails
Observability

In other words, they still need many of the things workflow engines have solved for
years.

The architecture is simply evolving.

Yesterday we had:

Workflow Engine
       ↓
      Tasks

Tomorrow we may have:

Agent
  ↓
Execution Engine
  ↓
Tools

The agent becomes responsible for planning. The orchestration layer becomes
responsible for reliable execution.

This is why I don't believe DAGs are disappearing. They are simply moving down a layer.

The mistake is thinking agents eliminate workflows. What they really eliminate is the
need to define every workflow in advance.

Agents are excellent planners. Workflows are excellent executors.

The future may not be Agents vs DAGs. It may simply be:

Agents for planning. DAGs for execution.

Worth reading

Advanced LangGraph Orchestration — Enterprise-Ready AI Workflow Management
Agentic AI and Temporal Orchestration — pairing agents with Temporal for durable execution
Apache Airflow · AWS Step Functions — the classic DAG-based orchestrators
GraphBit: A Graph-based Agentic Framework for Non-Linear Agent Orchestration — agents and graphs, together
Observability for Delegated Execution in Agentic AI Systems — the execution-layer concerns that don't go away

As a side project, and to better understand what happens inside a workflow engine, I'm
also experimenting with implementing a DAG engine in 4D. It started as a task scheduler
but evolved into a good opportunity to explore orchestration concepts from the inside.

The project is available here:
mesopelagique/Scheduler — Dag.md

A quick word on where I'm coming from: my hands-on experience with DAGs proper is
limited to Airflow for ML pipelines — pulling data from
the data warehouse, cleaning it, transforming it, and feeding the next stage. Beyond
that, as a developer I mostly live in CI tooling —
GitHub Actions,
GitLab CI,
TeamCity — which share a lot of common ground
with workflow engines: stages and dependencies, retries, caching/artifacts,
conditional steps, and approvals. Different vocabulary, same orchestration instincts.

macOS 27's AI dev ecosystem — and pointing 4D AIKit at a local model 🍎

Eric Marchand — Sat, 11 Jul 2026 09:44:36 +0000

For a year, Apple's on-device model was walled off — reachable only from Swift,
only inside an app you built in Xcode. macOS 27 tears that wall down. The same
Foundation Models are now scriptable from the terminal and from Python, and there's
a real framework story forming around them. Three pieces worth your attention.

Two models: System and PCC

There's now a hybrid setup with two tiers:

system — the on-device Apple Foundation Model. Default, free, fully private, nothing leaves the Mac.
pcc — a larger model on Private Cloud Compute. More capable, but subject to daily usage limits (higher caps come with paid iCloud+ tiers).

You pick per call, so the cheap private one is the default and you reach for PCC
only when a task needs the extra horsepower.

The `fm` CLI

fm comes pre-installed with macOS 27 — no install, just update and type fm.
It's built for scripting and automation, not just chatting:

The commands cover the obvious ground — one-shot generation, interactive chat,
token counting, JSON schema generation, plus availability and quota checks:

fm respond 'What is Swift?'
fm respond --model pcc --stream 'Summarize this article'
fm chat --instructions 'You are a coding assistant'
fm token-count 'Hello world'
fm schema object --name Person --string name --int age

The part that matters: `fm serve`

Here's the one most WWDC recaps skipped. fm serve starts an
OpenAI-compatible Chat Completions server, loopback-only:

url     http://127.0.0.1:1976
access  loopback-only

  · POST /v1/chat/completions
  · GET  /v1/models
  · GET  /health

OpenAI-compatible is the magic word. It speaks the same /v1/chat/completions dialect
as every other provider, so any software or library that already talks to an
OpenAI-style API can point straight at it — your existing client, SDK, agent
framework, or tool, unchanged beyond swapping the base URL to
http://127.0.0.1:1976/v1. Whatever you've already wired up for OpenAI now drives an
Apple Foundation Model (on-device or PCC), with no API key and no cloud bill.

For me that lands on 4D AIKit: point its base URL at
the local server and the same 4D code I'd aim at a remote provider runs against a local
model, no new component. But the point is general — anything OpenAI-compatible gets a
free local backend. That's a genuinely useful default for prototyping, and for anything
privacy-sensitive, maybe the production default too.

For the Python crowd, there's also an official
Foundation Models SDK for Python.

Core AI + a maturing Foundation Models framework

Alongside the CLI, Apple shipped Core AI —
a framework for running AI models directly in your app on Apple silicon — and a
solid round of upgrades to
Foundation Models.
The framework now has the pieces that were missing: tool calling, context and
conversation history, multimodal input (images, vision), and server-model access
behind the same Swift API. It's starting to look like something you'd actually
ship on, not just demo.

Worth reading

The pattern, again: a model that used to be locked inside one language and one app
becomes a local server speaking a standard dialect — and the moment it does, every
tool that already speaks that dialect (AIKit included) gets it for free. 🍎

EDIT — wait, I had `fm` first 😅

Funny postscript: I'd already built my own fm. Back when I wrote the
Apple Foundation Models post (mid-2025), I made a
little command-line tool — phimage/FoundationModelCli
— specifically so I could type fm and poke at Foundation Models from the terminal.
A year later Apple shipped a CLI with the exact same name. No collision, no hard
feelings… but for the record, I was running fm first. 🙂

ACP: Copilot in Xcode, without the plugin 🔌

Eric Marchand — Sat, 11 Jul 2026 09:44:24 +0000

There's a new standardization layer in the agentic-coding stack, and it's a good
one: the Agent Client Protocol (ACP). After MCP standardized what tools an
agent can reach, ACP standardizes how editors and agents talk to each other —
local or remote — so any ACP agent drops into any ACP editor with no bespoke,
per-vendor glue. It's developed in the open (JetBrains and Zed), and there's a
clean introduction if
you want the protocol view.

The reason this matters today: Xcode 27 speaks ACP. (It's in the developer
beta, and it's already turning up in the
26.6 RC.)

MCP vs ACP, in one line

Xcode 27 actually has two protocol layers, and it's worth keeping them straight:

MCP decides what an agent can do inside Xcode — read files, build, run tests, pull diagnostics.
ACP decides which agents are even allowed to connect in the first place.

So ACP is the front door, MCP is the toolbox once you're inside. Apple shipped
GitHub and Figma as launch plugin partners — but because the door is a standard,
you don't actually need their plugin. Any ACP-speaking agent can knock.

The trick: register Copilot CLI as a raw ACP agent

Copilot CLI can run as an ACP server, so you can wire it straight into Xcode
instead of installing the official plugin. In Xcode → Settings → Intelligence →
Coding Intelligence → Add an Agent…:

Name: Copilot
Executable: /opt/homebrew/bin/copilot (wherever Homebrew put it — which copilot)
Arguments: --acp

That's the whole registration. Xcode notes that ACP agents get full use of Xcode
and your project context, and it asks for consent before a new agent connects —
the protocol is permissioned by design, not a backdoor.

Pick your model with an env var

The fun part: you're not locked to one model. Add an Environment Variable to
the agent and pin whichever model you want — for example:

COPILOT_MODEL=claude-sonnet-4.6

So you get Copilot's harness and auth, driving the model of your choice, inside
Apple's IDE. "Use any LLM in Xcode" is barely an exaggeration.

Under the hood

If you want to see what Xcode is launching, the CLI flag is documented. --acp
defaults to stdio mode (ideal for an IDE spawning the process); add --port
for TCP instead:

copilot --acp --stdio      # stdio (default when --acp is passed)
copilot --acp --port 3000  # TCP

One caveat worth flagging: ACP support in Copilot CLI is still public preview,
so flags and behavior may shift. Tool-filtering and reasoning-effort flags, if you
pass them, apply per session started by the client.

Worth reading

The bigger picture: the N×M integration problem — every editor needing a custom
connector for every agent — collapses to N+M once both sides speak a shared
protocol. MCP did it for tools; ACP is doing it for the agents themselves. Xcode
adopting it this fast is the surprise. 🔌

DEV Community: Eric Marchand

acpdbg: let the agent sit at the debugger 🐛

acpdbg

Try it fast

Inside lldb — and inside Xcode

It's a try

Pipeline, Flow, or Chain? Picking the Right Tool to Wire LLM Calls Together

The naming trap

The real choice: library or orchestrator?

When you don't need either

A concrete chain

When Agents Become Planners, What Remains of Workflow Orchestration?

Worth reading

macOS 27's AI dev ecosystem — and pointing 4D AIKit at a local model 🍎

Two models: System and PCC

The fm CLI

The part that matters: fm serve

Core AI + a maturing Foundation Models framework

Worth reading

EDIT — wait, I had fm first 😅

ACP: Copilot in Xcode, without the plugin 🔌

MCP vs ACP, in one line

The trick: register Copilot CLI as a raw ACP agent

Pick your model with an env var

Under the hood

Worth reading

The `fm` CLI

The part that matters: `fm serve`

EDIT — wait, I had `fm` first 😅