Did I Build a Worse LangGraph?

When you build an orchestration tool for AI agents, there is an uncomfortable question you eventually have to ask:

Why does this need to exist when LangGraph already exists?

I recently tried to answer that question for vincent.

And the answer was not that LangGraph and vincent are completely different.

They aren't.

There is substantial overlap.

Both can coordinate agentic workloads. Both can express structured execution. Both can deal with parallel work, retries, long-running processes, and human checkpoints.

The real difference is the level of abstraction.

LangGraph orchestrates what an AI agent does.
vincent orchestrates what AI coding agents do to a software project.

That distinction has turned out to be much more important than I originally expected.

The Repository Is Part of the Workflow

In a typical agent orchestration system, the central abstraction is application state.

Conceptually:

state
  ↓
node
  ↓
new state

For software-development automation, there is another extremely important piece of state:

repository

A coding agent does not merely return structured output.

It modifies files.

Those files live inside Git repositories.

Changes may need to happen in isolated worktrees.

Parallel agents may produce separate branches.

Results may need to pass deterministic verification.

A human may need to approve them.

Eventually, those branches may need to merge.

And that merge may fail.

In vincent, those are not just implementation details around the agent.

They are part of the orchestration model.

Parallelism Means Something Different

Consider a fan-out workflow.

In a general-purpose agent graph, several nodes may execute independently and later combine their resulting state.

For coding agents, parallelism can mean something much more concrete:

main
├── agent-a branch
├── agent-b branch
└── agent-c branch

Each agent works in an isolated repository state.

The join is no longer only about combining application data.

It can literally mean:

git merge

And therefore it can produce:

merge conflict

That changes what the runtime needs to understand.

This Is About Defaults, Not Possibility

An important point in this comparison:

This is not a capability argument.

You can absolutely build repository-aware coding workflows using LangGraph.

You can put repository paths, commit hashes, branch information, diff metadata, and verification results into graph state.

You can implement worktree management.

You can implement merge semantics.

You can build approval gates.

You can integrate coding agents.

The difference is not what is possible.

The difference is what the runtime treats as a first-class concept.

LangGraph deliberately provides flexible, low-level orchestration primitives.

vincent deliberately provides opinionated software-development primitives.

Being Opinionated Has a Cost

That specialization is not universally better.

Quite the opposite.

LangGraph can be used to build an enormous variety of agent systems.

vincent intentionally has a much narrower domain.

Its workflows revolve around concepts such as:

• repositories
• coding agents
• commands
• checks
• worktrees
• branches
• approvals
• retries
• merging
• software delivery

If your problem has nothing to do with software-development automation, vincent is probably the wrong abstraction.

That is the tradeoff.

Generality gives you flexibility.

Opinionated semantics give you stronger defaults.

They Can Also Work Together

The comparison becomes even more interesting when you stop thinking about the projects as mutually exclusive.

A sophisticated architecture could look like:

vincent
   ↓
coding workflow
   ↓
custom agent
   ↓
LangGraph
   ↓
reasoning / retrieval / tools / memory
   ↓
repository changes
   ↓
vincent verification / approval / merge

LangGraph could power the intelligence inside an agent.

vincent could govern how that agent is allowed to operate against a real software project.

Those are different responsibilities.

The Full Comparison

I wrote a more detailed breakdown covering the architectural overlap, repository semantics, fan-out/fan-in behavior, human control, durability, and the tradeoffs of an opinionated coding-agent runtime.

You can read it here:

LangGraph vs vincent: generic graph primitives against an opinionated coding-agent runtime

I'd be very interested to hear how others building coding agents, AI development platforms, or LangGraph-based systems think about this separation.

Is repository-aware orchestration something that should live inside the agent framework itself?

Or does it make sense as a separate layer?

Comments

[Baptiste Le Bouquin]

The repository-as-state point is the strongest difference, and it's real: a coding agent doesn't just return structured output, it mutates files, and that mutation lives in git, not in the app state graph. That's a genuinely different orchestration model from LangGraph's generic state machine, not just a reimplementation.

The merge-conflict angle is where I'd dig deeper. Running parallel agents in isolated worktrees means the join step becomes a real git merge that can fail, and the retry semantics are totally different from a function call retry. Do you let the orchestrator feed the conflict diff back to the agents to self-resolve, or does that always go to a human? I've been curious whether an agent can meaningfully resolve its own branch conflict or if that's a hard human boundary.