Competitive & alternative-solution analysis
Bottom line: work-ledger has no competitor in the commercial sense — it is an internal system of record for a 2-human, 10→64-agent fleet, not a product with a market. Every category scanned (purpose-built agent trackers, PM tools with agent APIs, Temporal itself, a bare claim table, markdown, manual process, Zaruba extending his own platform) covers a slice of the five-part requirement bundle (atomic claim, durable dispositions, per-unit cost, Temporal-fit projection, evidence for kill gates) and fails on the rest — most decisively on durability past Temporal’s 72h retention and disposition/cost as a queryable joined record. The one substitute worth the full adversarial treatment — Temporal search attributes + visibility as the entire system of record — reaches only ~30% blended coverage and its two structural breakpoints (retention wall, search-attribute poverty) cannot be configured away. Verdict: build survives, scope shrinks — adopt every Temporal-native and Zaruba-native primitive that already exists (workflow-id claim, workflow_executions projection, tasks INFORMATION_REQUEST) and build only the durable business-fields table + external-claim guard nothing else in the landscape provides.
Scope & method
work-ledger has ~2 human readers (Robert, Tomas) and one write-side customer (Robert’s agent fleet, later possibly Tomas’s). There is no purchase funnel, no pricing comparison, no churn economics to analyze — this section evaluates substitutability, not market position: could an existing product, OSS project, platform primitive, or process do work-ledger’s actual job (claim-before-work at 64-concurrent + durable MIGRATED/DROPPED/DEFERRED/DEAD disposition + per-unit cost + one-way Temporal projection + evidence readable at M4/M8/M12) well enough that building is wasted effort? Sourced entirely from three prior research passes (competitive, prior-art, Temporal-native-case digests) plus repo recon into monorepo-development — every claim below is cited to its source pass. No fresh web research was run for this document; where a named candidate (claude-task-master) has no evidence in the source passes, it is flagged unknown rather than guessed at.
1. Landscape overview
| Category | Examples | One-line verdict |
|---|---|---|
| Direct — purpose-built agent claim/work trackers | beads, Backlog.md, claude-task-master, Vibe Kanban, Terragon/Conductor/sniffly | None model disposition+cost together; two are dead as businesses, one has open unresolved concurrency bugs, one is unresearched |
| Indirect — PM trackers with agent APIs | Linear (Agent API), Jira/Rovo, GitHub Issues/Projects/Agent HQ | Solve session supervision, not claim safety or bookkeeping; GitHub is actively rate-limit-hostile at fleet scale |
| Substitute — Temporal-native SoR | Search attributes + visibility, reusing the already-built workflow_executions projection |
Strongest substitute; ~30% blended coverage; retention wall (72h) is a structural, not tunable, breakpoint |
| Substitute — bare claim primitive | Postgres SKIP LOCKED table, no service |
Solves claim only; converges into work-ledger the moment dispositions/cost are added |
| Substitute — convention | Spreadsheet / git-native markdown board | Proven unsafe under concurrent agent writes (dated 2026 preprint), not a real candidate |
| Internal alternative | Tomas extends workflow-management himself |
Technically closest fit, organizationally the highest-risk option (bus factor of one, decision-bound owner, review-capacity ceiling) |
| Process | Manual (Slack, spreadsheet, ADRs) | Genuinely correct for ~dozens of component-tier dispositions; breaks at ~1000 unit-tier cardinality |
2. Direct alternatives — purpose-built agent work/claim trackers
| Tool | 2026 status | What it actually tracks | Decisive gap vs work-ledger | Source |
|---|---|---|---|---|
| beads (Steve Yegge, Dolt-backed) | Active but churning — Postgres backend built then rolled back 2 days before this research (2026-07-16) | Dependency graph + hash-based IDs (avoids sequence-counter collision across branches) | No disposition taxonomy, not cost-aware, no Temporal fit; open unresolved multi-machine merge conflicts on its own metadata table and zero chaos-test coverage on its Dolt backend | oss digest verdict; prior-art digest §2 citing github.com/gastownhall/beads issues #2466, #2765 (2026) |
| Backlog.md | Active, git-native markdown board — same files are the human and agent API | Task status as markdown/frontmatter fields | Proven unsafe at the exact failure mode work-ledger exists to prevent: a June-2026 arXiv preprint quantifies that under 2 agents each writing a different field to the same record, a file-based last-writer-wins tracker keeps one write and silently discards the other entirely | arXiv:2606.19616 (Sarkar, “Before the Pull Request,” June 2026), cited prior-art digest §2 |
| claude-task-master | — | — | Not evaluated — no evidence surfaced in any of the three research passes for this doc. Named in the brief; flagged as an explicit research gap, not a verdict. | none — unknown |
| Vibe Kanban | Company (Bloop) shut down Apr 10 2026; relicensed Apache 2.0, community-maintained; remote services died 30 days after the shutdown announcement, now local-only | Kanban board driving Claude Code/Codex/etc | Never had a claim primitive even while a going concern — status columns only, no dispositions, no cost, no Temporal fit. Stated shutdown reason: “vast majority are free users… couldn’t find a business model” — a business-model failure, not evidence the underlying claim/tracking problem was solved or unsolvable | competitive digest (a); [E7] |
| Dead/dying fleet-supervision tools — Terragon, Conductor, sniffly | Terragon shut down Feb 9 2026 (“didn’t reach traction for a sustainable business”); Conductor active but macOS-only, single-operator, $22M Series A team of ~6, free tier only, no shared claim registry; sniffly stale 11 months | Session supervision UX (live terminal views, kanban-over-agent-dispatch) | None of the three ever documented a cross-fleet atomic claim primitive, disposition taxonomy, or cost attribution — they solve watching agents work, not bookkeeping what they did | competitive digest (a); research/12 §2; [E7] |
Why none of these are actually substitutes: every direct candidate solves one narrow slice — claim-adjacent (beads), file-as-API convenience (Backlog.md), or supervision UX (Vibe Kanban, Conductor) — and the two candidates purpose-built closest to “agent task tracker” both have live, dated evidence of instability (beads’ schema churn, Backlog.md’s proven data-loss mode) rather than maturity. Two of the five named/discovered tools are dead as businesses. This is the same pattern the deep-dive found for the fleet-monitor market [E7]: nothing off-the-shelf, and what exists is either too narrow or actively regressing.
3. Indirect alternatives — PM trackers with agent APIs
| Product | 2026 agent-API maturity | Claim mechanism | Dispositions | Cost/unit | Decisive gap |
|---|---|---|---|---|---|
| Linear (Agent API) | AgentSession objects, well-designed lifecycle (working/waiting-for-input/error/finished), auto-updated from agent activity — genuinely good session modeling |
assignee field, poll-and-dispatch (OpenAI’s own Symphony reference implementation runs this way) |
No native concept of “attempt,” “blocking question with evidence,” or “disposition with evidence link” — would need to be encoded as custom fields/labels, i.e. rebuilding work-ledger’s schema inside a tool not built for it | Not documented | Whether assignee writes have any optimistic-concurrency guard is unverified — flag as unknown, not confirmed-unsafe; wrong vocabulary (“issue”) for a 2-human internal tool; external SaaS with pricing/roadmap Groupon doesn’t control |
| Jira (Rovo / Atlassian Intelligence) | Triage/JQL generation added 2026 | N/A | N/A | N/A | Documented failure mode is upstream of claim/cost entirely — “Jira tickets were never built for AI coding agents… PMs write vague epics… AI agents cannot walk over and ask clarifying questions” [dev.to, 2026]. Wrong vocabulary collision (this plan already bans “ticket”) and wrong failure class; not evaluated further |
| GitHub Issues/Projects/Agent HQ | Agent HQ (public preview Oct 2025 → GA push 2026) — “mission control,” unified audit trail merging agent and human actions into one log | Issue-assignment based; no documented cross-fleet atomic claim | Issue open/closed only; Agent HQ’s audit trail is the closest analog to an evidence log but still has no MIGRATED/DROPPED/DEFERRED/DEAD equivalent | Surfaces via org billing, not a per-unit field | The strongest negative evidence in the entire landscape. GitHub’s own infra is documented straining under agent load: 4 code paths share one 5,000-req/hr rate-limit budget; a single 50-session batch failure triggers 350 concurrent processes consuming 42,000 calls/hr — 8.4× the budget [techlogstack.com / lunar.dev, 2026]. A “10× capacity scaling initiative” begun Oct 2025 “was already obsolete” by Feb 2026 against real 30× demand [quasa.io, 2026]. GitHub added PR caps specifically to throttle AI-driven volume [coderabbit.ai, 2026-04]. Using a rate-limited external SaaS API as the atomic-claim substrate for a 64-concurrent internal fleet is a documented 2026 anti-pattern, independent of Groupon’s specifics |
Generic literature across all three: race conditions causing “duplicate operations and lost updates,” agents “duplicating effort” from misalignment, sequential-processing bugs re-merging already-merged records [arize.com, galileo.ai, getmaxim.ai — 2025-2026 aggregate, competitive digest (b)]. This is why an app-level “check the assignee field, then write” convention — which is what all three trackers offer — is structurally fragile at exactly the concurrency work-ledger targets, and why a DB-enforced atomic claim (not a convention) is the right primitive regardless of which tracker sits on top.
4. Substitutes — infrastructure-level
4.1 Temporal search attributes + visibility — the strongest substitute, full treatment
This is the only substitute that reuses infrastructure Groupon already operates — self-hosted Temporal, Postgres persistence, numHistoryShards: 512. It deserves the adversarial treatment given it in the Temporal-native-case research pass, not a one-line dismissal.
What already exists that makes this case arguable at all:
| Capability | Already built | Evidence |
|---|---|---|
| Temporal execution truth | Self-hosted cluster, sized for tens of thousands wf/day | repos/monorepo-infra/_documentation/temporal.md |
| Temporal→Postgres projection | workflow_executions table (status, progress, payload, result, timestamps), kept in sync by an execution interceptor + reconciliation cron |
workflow-management/schemas/workflowExecution.schema.ts, worker-core/interceptors/execution.interceptor.ts |
| Native atomic claim primitive | WorkflowIdConflictPolicy + WorkflowIdReusePolicy: REJECT_DUPLICATE — a second start of the same workflow-id returns WorkflowExecutionAlreadyStartedFailure, a genuinely atomic native claim |
Temporal docs |
| Blocking-question surface | tasks service, TaskType.INFORMATION_REQUEST, assigneeGroupSlug free-form queue routing |
tasks/interfaces/tasks.interfaces.ts |
Confirmed fact: zero search attributes are used anywhere in the greenfield today — this path is a net-new adoption, not “use what’s already there.”
Coverage per requirement (Temporal-native, zero new services):
| Requirement | Coverage | Why it stops there |
|---|---|---|
| Atomic external claim | ~55% | Workflow-id uniqueness is genuinely atomic, but only for a unit that is a workflow. v1 fleet = external Claude CLI sessions, not workflows |
| Dispositions surviving retention | ~10% | Namespace retention is --retention 72h; Temporal purges closed-workflow data from both persistence and visibility after retention. Kill gates are M4/M8/M12 — months out. Archival preserves Event History as replay-only blobs, not a queryable table |
| Cost attribution | ~45% | Fits an Int/Double search attribute, but purged with the workflow at 72h — no durable roll-up |
| Kill-gate evidence table | ~15% | Visibility list-filter has no joins, no aggregation; evidence capped at 2 KB / 255 chars per attribute; purged at retention |
| Cross-fleet visibility | ~40% | One namespace + a fleet search attribute filters live executions, but the durable store underneath is Temporal’s own schema, which you don’t own and which Temporal deletes |
Blended coverage of the system-of-record mandate: ~30%.
The breakpoints, named:
- B1 — the retention wall (decisive). Minimum retention is 1 day; 72h is the temporal-operate skill’s namespace-create example — nothing is provisioned yet, retention is a tuning knob; the structural purge argument stands at any realistic setting. Archival is replay-only, not queryable. Every requirement containing “surviving retention” is near-zero. A unit closed in month 1 must be re-readable at the M4 gate — Temporal has purged it within days.
- Escape hatch — bump retention to a year: keeps history, not queryability. Reads still route to either the 28-attribute visibility DB (no joins, no evidence beyond 2 KB) or full history replay. It also grows the visibility Postgres unboundedly with a standing fleet of unit-shell workflows the cluster was sized for business workflows, not unit-shells, and makes a second namespace’s schema+retention your system of record to operate. Escape hatch closed.
- B2 — search-attribute schema poverty. Self-hosted SQL visibility caps at 28 custom attributes/namespace (10 Keyword + 3 each of Bool/Datetime/Double/Int/KeywordList/Text), 2 KB per value, 255 chars per value. state + disposition + cost + attempts + blocking-question-id + evidence-URL-set + fleet + domain exhausts the Keyword budget, and an evidence-URL list overruns 255 chars. Search attributes are a filter index, not a record.
- B3 — two execution models; no unit-workflow in v1. External Claude sessions are not workflows. Using Temporal-native claim/state requires wrapping each session in a shell “unit workflow” that exists only to hold search attributes and await a signal — durably-executing machinery built solely to store a worse copy of the ledger row it’s substituting for.
- B4 — cross-plane signal gap.
taskssignals only Core-plane workflows; no cross-plane signal bridge exists yet (decision log, 2026-07-18). An internal-plane unit-workflow can’t be resumed by a Core task completion, and an external agent has no workflow to signal at all — the “route blocking questions throughtasks” leg needs at least one new exposed endpoint, denting the “zero new services” framing. - B5 — Grafana-over-visibility queries someone else’s purging database.
temporal_visibilityis Temporal-owned, retention-purged, un-joined to business columns, not a supported analytics surface.
Crossover point — when process-only costs more than the thin service: the composite bill to reach parity via this path is register+maintain custom search attributes, a shell unit-workflow definition, Archival config plus a projection that reads archived history (strictly harder than reading a live row), a SKIP LOCKED claim table for external agents anyway (B3), an exposed task-creation endpoint (B4), and a cron racing the 72h purge to snapshot data before it vanishes (B1). That is more code, more moving parts, and still fails the read — versus one table the fleet writes to directly. Process-only is cheaper only for a fleet that never faces a kill gate and never re-reads a unit older than 3 days; the program’s kill gates are M4/M8/M12 and the fleet monitor needs per-unit cost/rework data from day one, so that window is empty — process-only costs more than the thin service from essentially unit #1.
[Full sourcing: temporalCase digest, Temporal docs for retention/search-attribute limits, decision log 2026-07-18.]
4.2 Plain SKIP LOCKED table, no service
Postgres FOR UPDATE SKIP LOCKED for atomic multi-consumer claim without blocking is long-established and battle-tested (Que, Oban, pg-boss, graphile-worker) — high confidence, mature, and it is exactly work-ledger’s own chosen claim mechanism internally. As a standalone substitute, though, it solves claim only. The single most load-bearing finding across all four research passes directly rebuts “a bare claim table is enough”: a June-2026 arXiv preprint found that an advisory-lease-only condition produced the highest redundant-rediscovery count (180 instances) of any tested condition — mutual exclusion stops collision but not re-doing already-finished work. A claim table with no durable “already done, here’s the disposition and cost” record does not solve claim-before-work.
The honest framing (conceded directly in the Temporal-native-case pass): “add the disposition enum, the cost column, and the evidence link that the retention wall forces into that same durable store, and you have rebuilt work-ledger.” A bare SKIP LOCKED table isn’t a distinct alternative to work-ledger — it’s work-ledger’s first migration, described as if it were something else.
4.3 Spreadsheet / git-native markdown convention
Not a real candidate. The same arXiv:2606.19616 preprint that undermines Backlog.md (§2 above) applies generically to any file-based, human-or-agent-edited convention: concurrent field writes to the same record are silently dropped by last-writer-wins semantics, and a race-to-close between two agents is invisible in git history — the losing agent’s work “leaves no trace,” meaning standard PR-level telemetry cannot detect this failure class. At 10→64 concurrent agents this is not a hypothetical edge case, it’s the exact scenario multiplied 64×. Included here only because it is the honest zero-infrastructure default a rushed team reaches for, and the evidence against it is dated and specific rather than intuition.
5. Internal alternative — Tomas extends workflow-management himself
This is plan 001’s Option B (“Zaruba-Native Extension”) applied specifically to work-ledger: instead of Robert owning a new service, Tomas builds claim/disposition/cost machinery directly into his own platform.
Where it’s strongest: perfect DDD/schema fit by construction — one workflow platform, one task system, zero duplicate bounded contexts. If anyone can make Temporal-native work past B1/B2/B3, it’s the person who owns the namespace and can decide retention/archival policy unilaterally.
Where it breaks — organizationally, not technically:
- The same B1 (retention wall) and B2 (search-attribute poverty) breakpoints apply regardless of who builds it — Temporal’s architecture doesn’t change based on which team owns the code.
- 001’s own weighted decision matrix scored this option’s domain fit at 3/5 versus the recommended option’s 5/5, specifically flagging “Robert owns no context; semantic squatting in Tomas’s aggregates.”
- Review capacity is the documented scaling constraint at volume: AI-authored PRs wait 4.6× longer for review and land at 32.7% acceptance vs 84.4% for human-authored PRs (research/12 §1.7). Every change to work-ledger’s schema would queue behind Tomas’s own review bandwidth.
- Tomas is explicitly decision-bound today (“víc agentů mi nepomůže” — more agents don’t help me right now, research/12 §1) — his human hours already ARE the program’s rulebook. Adding fleet-bookkeeping ownership to that queue is the single highest-probability way to stall Robert’s own execution lane; 001’s pre-mortem #1 names exactly this failure mode (“the lane never existed… negotiation dragged; Robert built nothing for a quarter”).
- Ops burden and integration cost both land on the one person whose time is already the bottleneck resource of the entire program.
Verdict on this option specifically: technically the closest fit, organizationally the worst place to put new load. This is precisely why plan 001 scored it second (3.35) behind the two-lane thin factory (4.45) rather than first, and why the recommended shape reuses Tomas’s existing, already-built primitives (workflow-id claim, workflow_executions projection, tasks INFORMATION_REQUEST) without asking him to build or maintain anything new.
6. Manual process (Slack threads, spreadsheets, ADRs)
Not uniformly wrong — genuinely correct for one tier of the problem. Groupon already has an append-only decision log (reasons-and-decisions/07-decision-log.md, MADR-format, supersede-never-edit, git-durable) that both leads’ agents already import via CLAUDE.md/AGENTS.md. For the component-level dispositions — MIGRATED/DROPPED/DEFERRED/DEAD per legacy repo, ~dozens of them across the 26-repo sample [E6] — an ADR is a better fit than a database row: it’s a decision, not a bookkeeping event, and the log already exists at zero marginal infrastructure cost.
It breaks at cardinality. The ~1000 unit-level dispositions each carry a per-unit evidence link and cost — that’s per-work-unit bookkeeping, not an architecture decision. Hand-authoring an ADR per unit is, in the Temporal-native-case pass’s own words, “exactly the ‘table-per-process / worse Linear’ smell” the program’s own decision doctrine warns against. Split the tiers: component-tier dispositions stay in the ADR log (already correct, keep it); unit-tier dispositions need the durable table, because manual process silently stops scaling somewhere between “dozens” and “hundreds,” not with an error — with nobody reading it anymore.
7. Comparison matrix
Columns: Claim = atomic external claim @ 64-concurrent · Disp. = dispositions as durable record · Cost = per-unit cost attribution · Temporal fit = fits the one-way-projection architecture · Encore fit = native to the monorepo’s conventions · Ops = operational burden to run · Integ. = cost to integrate/adopt · Maint. risk = risk the option itself degrades or dies.
| Alternative | Claim | Disp. | Cost | Temporal fit | Encore fit | Ops | Integ. | Maint. risk |
|---|---|---|---|---|---|---|---|---|
| work-ledger (as scoped) | Yes — native SKIP LOCKED | Yes — enum+CHECK | Yes — column/attempt | Native — built as the projection consumer | Native | Low | — | Low |
| beads (Dolt) | Partial — unproven at scale, live merge-conflict bugs | No | No | No | Low — foreign datastore | Med-High | Med | High — active schema churn |
| Backlog.md | No — proven unsafe | Partial — free text only | No | No | Low | Low (but silent failure) | Low | High — dated proof of data loss |
| claude-task-master | Unknown | Unknown | Unknown | Unknown | Unknown | Unknown | Unknown | Unknown |
| Vibe Kanban | No | No | No | No | No | N/A (dead as company) | N/A | Realized — company shut down |
| Terragon / Conductor / sniffly | No | No | No | No | No | Low where alive | Low-Med | High (2 of 3 already dead/stale) |
| Linear (Agent API) | Unverified — no documented optimistic-concurrency guard | No — would need custom fields | No | No | No — wrong vocabulary, external SaaS | Zero self-hosted ops | Medium | Medium — vendor roadmap risk |
| Jira / Rovo | N/A — wrong failure class | N/A | N/A | N/A | N/A | External | N/A | Not evaluated further |
| GitHub Issues/Projects/Agent HQ | No — documented rate-limit anti-pattern at fleet scale | No — open/closed only | No — org-billing level | No | No | High under fleet load (throttling) | Med-High | High — infra “already obsolete” vs demand, Feb 2026 |
| Temporal SA + visibility | Partial (~55%, workflow-modelled units only) | No (~10%) — retention purges it | Partial (~45%, purged) | Is the source, not a substitute | Medium — reuses cluster, unowned schema growth | Medium-High (archival, crons, shell workflows) | High — composite exceeds the thin service | High — retention wall structural, not tunable |
| Bare SKIP LOCKED table | Yes | No by itself | No by itself | Neutral | High (it’s Postgres) | Low | Low | Low — but converges to work-ledger once completed |
| Spreadsheet/markdown | No — proven unsafe | Partial (free text) | No | No | Low | Zero (but invisible failures) | Zero | High — dated proof (arXiv 2606.19616) |
| Tomas extends workflow-management | Same B1-B3 breakpoints apply | Same B1 applies | Same B1/B2 apply | Native by construction | Perfect by construction, worst DRI fit (3/5 vs 5/5) | Shifts bottleneck to the program’s scarcest reviewer | High coordination cost | High — bus factor of one, decision-bound owner |
| Manual process / ADRs | No | Yes at component tier only; no at unit tier | No | No | Partial — reuses existing log | Low at component tier, unworkable at unit tier | Low | Low where scoped correctly |
Accepted unknown: claude-task-master was never evaluated in any research pass; cannot flip the verdict — even a perfect tracker fit would still fail the durable-disposition-past-retention and Encore-substrate requirements that eliminated every tracker above. Classify honestly as Unknown, not N/A.
8. Standalone product vs feature vs workflow vs data layer
It is a data layer with a thin workflow wrapper — not a product, and not really a feature of anything else either, because nothing else has the underlying model to be a feature of.
Two independent, convergent sources support this framing rather than one internal opinion:
01-initial-recommendation.md§1 independently frames work-ledger as “an accounting system, not an app.”- Paul Gross’s 2025 essay “Double-Entry Ledgers: The Missing Primitive in Modern Software” [pgrs.net, 2025-06-17] makes the identical argument for ledgers generally: durable value lives in the data model + invariants, with implementation (pgledger, TigerBeetle, “your own custom code”) kept explicitly separate from the modeling pattern — arrived at independently of this program.
The 2026 market confirms this by absence, not presence: nothing is sold as “the AI-fleet work ledger product,” because in every adjacent success story found (OpenAI’s Symphony, GitHub’s Agent HQ), the durable value is the data model wrapped in the thinnest possible glue — Symphony ships as a spec plus a poller, not a service, and OpenAI explicitly declined to productize it (“the company does not plan to maintain Symphony as a standalone product, treating it as a reference implementation” [helpnetsecurity.com, 2026-04-28]). No roadmap feature validated by any 2026 evidence (views, priorities, notifications, comments) belongs in scope — every company that shipped that shape (Vibe Kanban/Bloop, Terragon) is now defunct as a business, for reasons unrelated to the underlying technical need.
Practical read for this doc: stop calling the MVP “small” as if it were a slimmed-down product. It’s correctly sized already — one table, a claim guard, two views — because a data layer doesn’t have a smaller edition, it just has fewer columns.
9. Absorption question — 18-month horizon
Will Temporal, GitHub, or Zaruba’s platform absorb this within 18 months, and is that acceptable?
| Absorber | Likelihood (18mo) | Why |
|---|---|---|
| Temporal (as a platform) | Low. | B1 (72h retention wall) and B2 (28-attribute visibility cap) are architectural facts of self-hosted Temporal, not roadmap items Groupon controls or that Temporal has signaled changing. No evidence found of announced changes to either. Even a unilateral retention bump doesn’t solve queryability (§4.1 escape-hatch analysis) — the gap is structural. |
| GitHub (Agent HQ / unified audit trail) | Low-medium, and only for a different slice. | GitHub’s own 2026 trajectory (Agent HQ’s unified audit log) moves toward “one log of record for agent+human actions” — directionally similar in spirit, but it’s PR/issue-level, rate-limited, and has no disposition/cost primitives. More plausible GitHub absorbs review-observability over the next 18 months than unit-level claim/cost/disposition — those are different problems that happen to rhyme. |
Zaruba’s platform (workflow-management / fleet monitor) |
Medium-high, and this is the one that matters. | The Temporal-native-case pass’s own concession: “the durable per-unit table becomes mandatory… whether it ships as ‘work-ledger service’ or ‘the monitor’s schema’ is an org-boundary call, not a build/no-build call.” It is plausible and even likely that within 18 months the service boundary shifts — work-ledger’s table gets folded into the fleet monitor’s schema, or Tomas’s platform grows a native disposition concept once his own domain migrations hit the same cardinality problem Robert’s fleet hits first. |
Why service-boundary absorption is acceptable, and why absorption of the underlying model would not be: per §8, the durable value is the schema + invariants, not the service wrapper. If the fleet monitor or Zaruba’s platform absorbs the table within 18 months, nothing of value is lost — that is exactly the kind of consolidation an internal, disposable, schema-shaped tool should welcome, and it is explicitly named as an open org-boundary question rather than a risk in the source research. What would be a real failure is if Groupon built toward an imagined future where Temporal or GitHub natively solved disposition+cost+evidence and could be adopted wholesale — no evidence in any of the four research passes supports that happening on any timeline, let alone 18 months. Build for the schema to survive a service-boundary merge (plain Postgres, no exotic coupling to the Encore service shape) and the absorption question stops being a risk to design against.
10. Competitive verdict
What work-ledger must do that nothing else in the landscape does:
- Atomic claim across both execution models — workflow-modelled units (via Temporal workflow-id uniqueness, already free) and non-Temporal external Claude sessions (v1 fleet reality) — without collapsing into either pure Temporal-workflow semantics (fails for external sessions, B3) or file-based last-writer-wins semantics (proven unsafe, arXiv:2606.19616).
- Disposition as a durable record reachable past Temporal’s 72h retention, readable unchanged at M4/M8/M12 kill gates. This single property is where every substitute scores near-zero — including Temporal itself.
- Per-unit cost joined to disposition and evidence in one queryable place. No commercial vendor scanned (Devin, Factory.ai, Codex, Cursor, Jules) publishes per-unit cost at all; GitHub’s is org-billing-level; Temporal’s search-attribute version is purged with the workflow.
- One shared vocabulary two fleets can claim through without colliding, avoiding the dual-write / two-sources-of-truth failure mode that the Vitess, Netflix Conductor, and general dual-write literature all converge on as a solved-and-known anti-pattern when violated.
What work-ledger must NOT try to compete on:
- A UI or kanban surface. Every UI-forward competitor in this landscape (Vibe Kanban, and by extension Devin Desktop’s Agent Command Center, Cursor’s Agents Window) is either defunct as a business or solving single-operator supervision, a different problem. Grafana + SQL is the entire human surface by design; adding screens is the single most-validated way to become “a worse Linear that two people use” (
01-initial-recommendation.md). - General-purpose PM features. Priorities, sprints, comments, notifications, assignee routing — every company that shipped this shape around agent work in 2026 (Vibe Kanban/Bloop, Terragon) is now defunct, for business-model reasons that would apply equally to an internal build that grows the same surface out of habit.
- Being the execution engine. Temporal already owns execution truth and already has a working, atomic, native claim primitive for workflow-modelled units — work-ledger must consume that, never re-derive a parallel lifecycle state machine (the exact two-sources-of-truth failure named in plan 001’s pre-mortem #3).
- Being a market-shaped “AI fleet work board” product. No such category exists in 2026, confirmed by two independent research passes finding zero commercial or OSS coverage of the bundle. Building toward an imagined market inflates scope; building toward Robert’s and Tomas’s actual two-user, one-fleet (today) need keeps it a data layer, which is the size it should be.
Net effect on plan 001’s BUILD THIN verdict: survives, and narrows. Nothing in the competitive, indirect, substitute, internal, or process landscape covers the requirement bundle — but the Temporal-native-case pass’s own breakdown shows roughly a third of naive plan-001 scope (a full parallel state machine, claim mechanics for workflow-modelled units) is better sourced from primitives Zaruba’s platform already has running. The build that survives this analysis is smaller than the build plan 001 originally scoped: the durable business-fields table (disposition, cost, attempts, evidence, blocking-question ref) plus an external-claim guard for non-Temporal agents plus two SQL views — not a parallel lifecycle engine.