Many agents.
One shared direction.

The problem

A project’s brief can change while its agents are still working. Outputs may depend on an old audience, an outdated API contract, or instructions that have since changed. Restarting everything repeats useful work; carrying everything forward can preserve the wrong assumptions.

We are exploring a workspace that makes these dependencies explicit, identifies work affected by a change, and helps the team continue with an inspectable plan.

The product direction

• Agent contracts: roles, instructions, permitted tools, expected outputs, and budgets.
• Scoped context: versioned sources and relevant upstream artifacts for each task.
• Coordination: dependencies, handoffs, shared decisions, and human review points.
• Change-aware execution: a proposed replay plan that preserves work when its recorded inputs remain valid.
• Evidence and costs: attributable output records, unresolved checks, and cost per accepted deliverable.

The first workflow is preparing a small software release. Repository connections, persistent collaboration, and broader project workflows are planned extensions.

What works today

The public prototype runs entirely in your browser. It includes six agent roles, three editable brief inputs, versioned dependency records, instruction editing, transitive invalidation, per-agent and per-run sample budget checks, and a downloadable activity ledger.

When an input changes, working JavaScript compares its revision with the saved dependency graph. Replaying affected tasks creates new dependency records in order and preserves the revisions of unaffected artifacts. Unknown dependency coverage conservatively marks all tasks for replay.

Dependencies are authored fixtures. The prototype does not infer dependencies, run models, execute code, connect repositories, provide authentication, or enforce production access policies. Its output records are generated descriptions, not AI-generated deliverables. All prices and task costs in the demo are illustrative.

How Claude fits

The planned integration uses the first-party Claude API. Claude would interpret the project brief, propose tasks and dependencies, prepare relevant context for each role, and identify possible changes to assumptions when new instructions arrive.

Specialist agents would work in separate contexts and return structured artifacts. Claude-assisted review would connect claims to available sources or test evidence and identify unresolved questions. The application would retain versioned records, execute permitted tools, reserve budgets before dispatch, and record actual usage.

Model-proposed dependencies can be incomplete. Reuse decisions need runtime source tracking and validation; uncertain coverage should lead to broader replay or human review. A model’s assessment alone would not certify output correctness or authorize an external action.

Technical foundations: Claude tool use and structured outputs.

How we will test the efficiency hypothesis

1. Prepare a held-out set of software tasks with controlled audience, platform, and API changes.
2. Compare a full rerun, a simple manually maintained dependency plan, and Claude-assisted change planning.
3. Keep task inputs, model versions, acceptance tests, and tool access comparable. Repeat runs to capture variability.
4. Measure total API cost, planning overhead, latency, unnecessary rework, missed invalidations, and accepted task outcomes.
5. Report negative results and failures alongside any savings. Lower spend is useful only when the agreed quality checks continue to pass.

The demo assigns fixed synthetic costs to tasks and adds a $0.008 analysis allowance. It does not use provider prices or live token counts. It can show a plan with no cost advantage; that is an intentional part of the example.

Positioning and alternatives

Agent orchestration, memory, budget controls, and evaluation already exist in products such as CrewAI, LangSmith, and Claude Managed Agents. Incremental execution and dependency tracking are established ideas.

Our product hypothesis is that a focused, accessible experience for changing project goals—connecting decisions, task dependencies, preserved outputs, and measured rework—can be useful to small teams. That differentiation needs customer validation and live comparisons. We do not claim a novel algorithm or an uncontested market.

The next product milestone

Connect the first Claude workflow: turn a software brief into scoped agent tasks, revise one requirement, and inspect the resulting replay plan. Record actual usage and evaluate change planning, context selection, and evidence review against the baselines above.

The intended result is a reproducible comparison of cost and accepted output quality for a real end-to-end workflow. Team feedback and the evaluation results will determine what we build next.

OneChorus is an independent project. No program acceptance, partnership, customer traction, or production deployment is claimed.

Data in this prototype

The demo has no user accounts, uploads, tracking scripts, or collection forms. Your sample edits stay in the tab and disappear when you refresh. An exported JSON file contains the sample state and your local edits. Ordinary hosting access logs may still be recorded by the hosting provider.

A future connected product will need a separate data policy for repository content, credentials, retention, and model requests before accepting user data.

Let’s talk about your workflow

Questions about OneChorus, product feedback, or a workflow you would like us to explore? Get in touch at nakyuz@onechorus.stream.