Why the planner commits to a graph before anything runs.

Because you cannot parallelise or budget a plan you have not written down yet. That is the whole design decision behind Sextant, and everything else in it follows from that one choice.

TypeScript · MIT · ~820 LoC kernel · 106 tests

What it is

Sextant is a Plan-and-Execute multi-agent orchestrator. You give it a goal. A planner model turns that goal into a directed graph of tool calls. The kernel runs the graph in topological order, executing independent nodes in parallel up to a concurrency cap, and hands you a synthesis at the end with the full cost broken out.

The name is the design. A sextant fixes your position by combining sightings taken from several angles. The planner picks the angles, the specialists take their sightings at the same time, and the synthesis fixes the position.

The three patterns, and the trade you are making

Nearly every serious agent brief lands on one of three shapes. None of them is free.

We took the middle one and tried to fix its weakness rather than pretend it is not there. A committed plan is brittle when reality shifts mid-run, so the kernel is allowed to replan, but only within a hard cap.

What a real run looks like

Here is a recorded run, not a diagram. The goal was a comparison question about agentic orchestration frameworks. Sonnet read the word “compare” and fanned the plan out into three parallel web searches feeding one synthesis node.

[planning]
  claude-sonnet-4-6 -> 4-node DAG ($0.006339)
    search1      (web.search)
    search2      (web.search)
    search3      (web.search)
    summarize    (synth.summarize) <- [search1, search2, search3]

[executing]
  ok  search2      11.6s   $0.0358
  ok  search1      11.7s   $0.0338
  ok  search3      13.1s   $0.0349
  ok  summarize     5.3s   $0.0059

[summary]
  Wall clock:       23.4s
  Total cost:       $0.116665  (under cap)

Three searches took about 12 seconds each and ran at the same time, so the whole run finished in 23.4 seconds rather than the 42 it would have taken in sequence. The kernel held the synthesis back until all three resolved, then passed their outputs through working memory. That is the payoff for committing to a graph first: the parallelism is visible in the plan before a single token is spent.

Cost is a first-class number

A real research run costs roughly $0.05 for a single-search question and $0.12 for a three-angle comparison, on Sonnet as planner and Haiku as specialists. Every node reports its own spend and the run aborts if it crosses a configured cap.

This matters more than it sounds. Agent systems that discover their cost after the fact are impossible to put in front of a client. Knowing the shape of the graph before execution means knowing roughly what the answer will cost to produce.

Bounded replanning

Each node carries Zod preconditions. After a node completes, a hook re-checks the preconditions of everything downstream against the new state. If one fails, the planner is called again with the state diff and the id of the node that broke.

The word doing the work there is bounded. There is a replan cap per run and a separate cap per node, and the run fails cleanly once it is exhausted rather than looping. Retries are counted separately from replans, because a flaky API call and a wrong plan are different problems and deserve different budgets.

What it is not

It is not a LangGraph replacement. LangGraph is battle-tested, has persistence and conditional edges, and if a team is already productive on it they should stay there. It is not a framework either. The kernel is short enough to read in one sitting, and forking it is the intended way to use it.

The honest positioning is narrow: this is for teams who would rather own 820 lines of orchestration code than take a framework dependency. That is a real preference and a defensible one, but it is a preference, not a benchmark win.

Where it actually stands

The kernel and the Anthropic provider are shipped and live-verified, which covers planning, parallel execution, cost accounting and a working demo against real web search. Retrieval, observability and the judge harness are specified and gated on whether anyone wants them.

Saying so matters, because the gap between a README and a running system is where most agent projects live. The numbers quoted above come from runs that happened. The numbers for the later phases would be targets, so they are not quoted at all.

Known ways it breaks

A pathological tool can keep failing the same precondition and burn through the replan cap. Caps and tests exist for exactly that, and it still ends the run rather than producing an answer. It is TypeScript only, so a Python-first team is a poor fit today. And the plan is only as good as the planner: if the model misreads the goal, it commits to a bad graph early and you pay for the whole thing before you find out.