/Understudy
A new Maestra primitive

Your apps learn the part. Then they play it.

An understudy sits beside a method your Maestra app is already built from. It watches how your team handles that one task, learns it, and only steps on stage once it has earned the role, with a number to prove it.

Rehearsed by your team. Performed by your software.

See how it worksA five-minute read.

Why this is even possible

Every Maestra app is born automatable.

Most business software was built for hands. The only way to make it do anything is a person clicking through screens, so the only way to automate it is a bot pretending to click. It is brittle, and it can only reach what is on screen.

A Maestra app is built differently. It is a list of typed actions, its methods, and every screen, API, and agent is just a window onto that list. So a person clicking Escalate and a model calling escalateTicket are the same event: same action, same rules, same line in the log.

Think of a stage production. The understudy doesn’t get a different script, a different set, or a different exit. They learn the same blocking as the lead and walk through the same doors. That is the difference between hiring a stand-in who improvises and one who knows the show.

This is why you can’t bolt it onto leased software. It isn’t a feature you add. It is how the app is built.

Two origins
triage · #5121ERR timeout · P1
ResolveEscalate
understudy:triage
no interface — direct call
The same door
escalateTicket({ ticket: "#5121", priority: "P1", actor: "understudy:triage" })
One log
13:58resolveTicket #5090 P2 ✓understudy:triage
13:58resolveTicket #5090 P2 ✓jordan@harbor
13:54escalateTicket #5088 P1 ✓understudy:triage
13:54escalateTicket #5088 P1 ✓taylor@harbor
13:49sendReply #5084 ✓sam@harbor
the only field that differs ↑

The shape in code

An understudy is a small file that sits next to a method.

The method stays exactly as it is: it validates, checks permissions, and applies the change. The understudy’s only job is to propose what the method should do. The method still decides. The agent walks through the same door as every person, and it can do nothing the app didn’t already allow.

sendReply.understudy.tsWRITTEN BY MAESTRA
1defineUnderstudy(sendReply, {
2  // The ticket the person saw, never their decision.
3  subject: (ticket) => ({ ticketId: ticket.id }),
4
5  // Propose the reply a careful teammate would send, or step back.
6  propose: async (ticket) => {
7    if (mentionsLegal(ticket)) return abstain(); // a person handles this
8    const body = await draftReply(ticket);
9    return { input: { ticketId: ticket.id, body } };
10  },
11
12  // Graded against the reply the person actually sent.
13  grade: matchesTheTeam,
14});
The contractThe understudy’s output is exactly the method’s input. Nothing to keep in sync, nothing that can drift. It can also step back, and an honest “a person handles this” is a first-class answer.

Shadow ledger · sendReply · last 30 days

87%

would have agreed with your team

558 agreed84 to learn from
Shadow running

Put an action in shadow and nothing changes for your team. Every time someone does the task, the understudy quietly does it too, filing what it would have done next to what actually happened. Nobody relies on its decisions. You are just building the record that tells you when it’s ready.

Paired decisionslast 6 of 642
Your teamThe understudy
#5121Send how-to replySend how-to reply✓
#5108Ask for detailsAsk for details✓
#5097Escalate to a personSend how-to reply≠
#5090Send and closeSend and close✓
#5084Replied by handStepped back · legal thread✓
#5071Refund and apologyRefund and apology✓

The 13 percent where the understudy and your team part ways isn’t failure. It is the most valuable thing here: the exact cases where your team’s judgment and the model’s diverge, captured as they happen. That is the training set, writing itself.

It records app actions only, never keystrokes or screens, and it belongs to your organization. Nobody is being watched. The repetitive parts of the job are earning their own automation.

The loop

The role is earned one task at a time.

No leaps of faith. An action moves up only when the numbers clear the bar, and every promotion is a reviewed change you can undo.

manualapproveautosendReply87%
01Watch

Your team works the way it always has. Every action becomes a clean demonstration. There is nothing to opt into.

02Shadow

The understudy runs silently beside your team. You watch the agreement number climb before anything is handed over.

03Approve

A person approves, edits, or rejects what the understudy drafts. The team moves faster, and every correction becomes training data.

04Perform

Once the numbers hold, the action runs on its own. Exceptions still go to a person, and shadow keeps running to catch drift.

Not every action climbs all four rungs. A reversible one can go straight from shadow to performing on a slice of its traffic first. Approve is the permanent home for actions you never fully hand over, like anything that sends, publishes, or charges.

What you end up owning

Your team’s judgment becomes a model you own.

Here the stage metaphor breaks, on purpose. Leased software has spent a decade collecting how you work and selling it back as AI features. This turns that around.

Training here means one specific, well-documented recipe: supervised fine-tuning, then preference tuning. Take an action’s graded pairs, the context in and the decision out, and teach a small model to make that one call at a fraction of the cost. It drops into the understudy’s model slot like any other option, private to your organization.

Every run trains several candidates. Only the one that agrees most with your team ships, scored on held-out decisions against your own rubric. An update that would lose ground you had already won doesn’t ship.

Not RAG.

Facts stay in retrieval, where they belong. Habits move into the weights.

Not a copilot.

A copilot sits next to a tool it can’t operate. An understudy walks through the tool’s own door.

Not one big “company AI.”

A portfolio of small models, one per task, each with a record of exactly what it learned from.

modelfrontier → tuned/support/sendReply
autonomyshadowunchanged
Promote the model

It stays in shadow, proposing beside your team. The 87% you already trust becomes the before-and-after, at no risk.

Promote the role

A separate decision, later, argued from that model’s own live numbers. Demotion is undo.

Model cardsupport / sendReply · v4

Drafts customer replies. One task, trained on your team’s decisions.

87%Held-out agreement
with your team · rev 4
was 80% at rev 1
Source app
Front Desk
Method
sendReply
Trained on
642 graded pairs
Demonstrated by
your team · 9 people
Base model
open weights · 9B
Recipe
SFT → preference
Artifact
adapter · ~180 MB ↓
Owner
your org · private
Trained on your work, and only your work. Never pooled with anyone else’s.SERIAL 7C·A1·3E·08
slot sendReply.understudy.ts

The economics

Small models, real numbers.

Base modelsOpen-weight families
TrainingStandard open tooling
ServingGPU-resident inference

Every component is standard, proven, and open: the same stack any serious ML lab runs. What nobody else ships is the arrangement: it runs itself, per customer and per task, trained on your team’s graded decisions and scored against your own definition of correct.

Base model

Open weights, kept private to your organization. Small and mid-size classes by default, larger on request.

4–20B params
Training set per action

A busy queue produces enough in about a week. Scale further later if you like.

hundreds → millions
One training run

Duration scales with the set. Reproducible: pinned dependencies, fixed seed, dataset fingerprint in the report.

minutes to hours
Training price

Priced per token of training data, so a typical action costs dollars, not a subscription.

priced per M tokens
The model artifact

An adapter: megabytes, not gigabytes. Small enough to hand you as an export.

a few hundred MB
Latency

Resident on the GPU around the clock, so there are no cold starts.

~50 ms to first token

The anatomy of a Maestra app

Every Maestra app is already shaped to hold understudies.

A learning agent needs six things. A Maestra app already has all six, built in for reasons that predate understudies entirely.

01The score

what the app should do, in writing

→ grading rules
02Methods

the typed list of every action

→ a fixed action set
03Scenarios

repeatable test worlds in every app

→ factual grading
A MAESTRAAPP
04Rubrics

the grading checklist, from the score

→ yes/no scoring
05One log

every interface calls the same methods

→ demonstrations, day one
06The plumbing

catalog, metering, audit, roles, SSO

→ a runtime already running

That is why the loop is hard to find anywhere else. Asking a vendor for a model trained on your own operations usually gets you a consulting engagement, not a product. Here an organization learns from its own work, on infrastructure it already runs.

Two pieces that compound

You start earning before you start training.

01Understudies

An understudy gets to work the day you switch it on: routing, drafting, escalating, deciding when to hand a case to a person. None of that needs machine learning. It is ordinary logic and model calls, with the ladder and the paired ledger already doing their jobs.

02Fine-tuning

Fine-tuning takes that same work and turns it into a small model you own. It clicks into the understudy already running: same file, same grading, nothing new to learn. You aren’t adding a system. You are swapping in a better model.

The part that’s easy to miss: an understudy starts banking its record the day it goes live, long before training crosses anyone’s mind. By the time you want the model, the data already exists.

Keep your judgment in the building.

Move your operations out of leased software and into methods you own. Your team’s ordinary work becomes demonstrations. Understudies shadow until they’ve earned each part, and you decide when the curtain goes up.