Version N+1 · Crusoe Hackathon

Build the feature.
Test it. Learn what to build next.

AYA turns a working reference into a tested component for your repository. It records what worked, what failed, and what each attempt cost. The long-term goal is to use customer feedback to choose better features and cheaper workflows.

94-second recorded demo · timing condensed · Download video · Presentation slides

01 · Improve the product

Recover a capability.
Deliver a real PR.

Hermes investigates a Fireworks SQL workflow with REA, implements a Crusoe component, and repairs the failure found by independent tests.

Review the delivered component ↗
Reference → component → checks → pull request
02 · Improve the process

Change the workflow.
Keep the evaluator fixed.

MASS proposes workflow changes. Langfuse records actual actions and scores. AYA selects verified development answers for a real Crusoe training job.

Inspect the MASS adapter ↗
Measure → compare → retain → train
Target outcome · intended, not measured

A feature that works. A team that learns.

Start with a specification and a reference. Recover the component, check it independently, and deliver a pull request with CI. Release it to a small customer group. Use what you learn to decide the next feature and the next workflow.

01 · Correctness

Match the behavior you asked for.

An independent contract checks the component before it enters your product. Failures return to the agent for repair.

02 · Lower total cost

Choose the cheapest workflow that passes.

Count model calls, compute, review, repairs, and verification. The goal is a lower cost per accepted feature, not more agent activity.

03 · Retained knowledge

Keep the evidence in your organization.

Save contracts, source provenance, tested approaches, failed hypotheses, and permitted customer feedback in an exportable record that survives a model change.

04 · Customer validation

Find out whether the feature matters.

Use a limited rollout to measure adoption and willingness to pay. Feed that evidence into product and workflow decisions.

These are target success criteria. The prototype has produced real PRs and a completed Crusoe training job; checkpoint deployment and a quality gain remain unproven. Read the actual experiment record and limitations ↗

The next step

Measure value beyond the pull request.

A passing feature is the engineering outcome. A customer choosing to use and pay for it is the business outcome. AYA's intended loop connects the two while keeping the evidence available for the next decision.

Future work includes controlled rollouts, customer feedback integration, and cost per validated paying-customer outcome. No revenue or customer improvement is claimed. Pricing, sales, and distribution also affect results. Read the proposed operating model ↗

Inspect the work.