Working AI workflows, not slideware

1. Ingest

Email, chat, and web-form tickets are normalized into one shape and queued.

2. Classify

One bounded model call (Claude on Amazon Bedrock) returns a category, priority, short summary, and a confidence score.

3. Route

Configurable rules decide what happens: outages page on-call and open an engineering ticket; confident billing, bug, feature, and how-to tickets go straight to the right queue.

4. Review

Anything the model is unsure about goes to a human review queue with approve / override — low confidence never auto-routes.

Why it holds up in production

• Full audit trail for every ticket: what the model said, which rule fired, and why each action was taken
• Rules and prompt live in config, so the same pipeline is re-pointed at a new company in hours, not weeks
• MCP tools let an AI agent operate the pipeline — read access by default, write access opt-in per tool

Try it in two minutes

1. Pick an example ticket — or write your own messy one
2. Watch it get classified and routed in a few seconds
3. Open the review queue and approve or override the model

1. Ingest

A shot handoff — its ID, current stage, artist, and notes — is normalized and queued.

2. Classify

One bounded model call (Claude on Amazon Bedrock) reads the artist's notes and returns a readiness verdict — ready, needs revision, or blocked — with reasoning and a confidence score. It does not decide what the next stage is; that's fixed, known sequencing, not a judgment call.

3. Route

The next stage is looked up from a configured pipeline order, not guessed by the model. Blocked shots always escalate to a supervisor; anything the model isn't confident about goes to a coordinator; confident, ready shots auto-advance to the next stage's queue; shots needing revision go back to the artist with the reasoning attached.

4. Review

Anything the model is unsure about goes to a human review queue with approve / override — low confidence never auto-advances.

Why it holds up in production

• Full audit trail for every handoff: what the model said, which rule fired, current stage and next stage
• Same pipeline, second industry: this is the identical underlying system that runs the support-ticket demo, re-pointed at animation production by changing only the prompt, the routing rules, and the pipeline's stage order
• MCP tools let an AI agent operate the pipeline — read access by default, write access opt-in per tool

Try it in two minutes

1. Pick an example shot handoff — or write your own coordinator note
2. Watch it get classified and routed in a few seconds
3. Open the review queue and approve or override the model

1. Stream

Render-farm metrics stream through Amazon Kinesis tick by tick. In the demo you pick a scenario and watch about 50 seconds of a night on the farm arrive live.

2. Detect

Plain statistics, no model: each metric learns its own normal, then rolling EWMA / z-score rules flag spikes, sustained excursions and slow drift. A frozen or silent metric is flagged as a monitoring fault. Every window is scored and stored, and metrics that move together on one render pool are grouped into one incident.

3. Explain

Only after something is flagged, one bounded model call (Claude on Amazon Bedrock) reads every metric on that pool plus its recent changes and incidents, and returns ranked likely causes (a bad node, a driver roll-out, a heavy asset publish, shared storage), what to check first, a severity and a confidence score. It diagnoses infrastructure only: it never decides whether something is anomalous, and never judges the work.

4. Dispatch

A fixed table, not the model, turns severity and confidence into log, ticket or page. Explanations the model isn't sure about go to a human instead of being dismissed. On-call can acknowledge, escalate or dismiss with a note.

Why it holds up in production

• Detection is 100% deterministic and unit-tested: the model is called only on already-flagged windows, so a quiet night costs nothing and false alarms can't be talked into existence
• Operations, not art: the model reads infrastructure metrics and is instructed never to comment on the creative content or quality of any shot
• Full audit trail for every alert: the detector rule and z-score, exactly what the model was shown, its answer, which dispatch rule fired, and who acknowledged it
• Works alongside the render manager the studio already runs (AWS Deadline Cloud, Deadline 10, Tractor, OpenCue): it watches the farm's infrastructure, not the job queue, and can replay history in Deadline Cloud's own export format
• MCP tools let an AI agent work the anomaly feed. Read access is on by default and write access is opt-in per tool; no tool can change a threshold or pick the action

Try it in two minutes

1. Pick a scenario: a normal night, a node slowing after a driver update, a burst of failed frames, a frozen license monitor, the whole pool slowing down at once, or a night replayed from a Deadline Cloud export
2. Watch the metrics stream in and the windows get scored live. Normal scenarios should stay quiet
3. When something flags, read the diagnosis, then acknowledge, escalate or dismiss it

1. Detect

Your upload goes to private storage and is checked three times for size and length. Plain code measures every frame and the sound, and picks out the few frames that might show a slate: a steady, detailed hold. Amazon Rekognition moderates sampled frames, and every one of those candidate frames, before any AI call.

2. Read

One bounded multimodal call per candidate frame (Claude on Amazon Bedrock) answers one question: is a slate in this frame, and what is written on it? Production, roll, scene, take, INT/EXT and day/night each come back with their own confidence. Reading the board is the only thing the model does.

3. Sync

The sync point is found by signal processing, not AI: a sharp rise in the sound matched to the frame where the sticks snap shut. Take boundaries are fixed rules on the slate times, snapped to whole frames.

4. Review

Any field read below its confidence threshold, or that breaks a rule (a take that isn't a number, a roll that differs from the rest of the file), is shown next to a crop of the actual slate for a person to confirm or correct. Nothing is guessed. Then ffmpeg cuts each take and writes a JSON and CSV manifest.

Why it holds up in production

• It reads, it doesn't judge: the model transcribes what's written on the board, the same thing a loader or DIT would type. It never decides which take, shot or moment is good; that stays with the editor
• Only one step uses AI. Candidate detection, clap sync, take boundaries and the review rules are deterministic Go with heavy unit tests, so the same footage always cuts the same way
• Uncertainty goes to a person, not a guess: low-confidence or rule-breaking fields block export until someone checks them against the slate, and the manifest records who confirmed or corrected what
• Built for real uploads from strangers: a required rights confirmation, 15-minute and 1.5 GB limits, moderation before any AI call, per-session rate limits, raw footage deleted within 2 hours, and usage alarms that switch uploads off on their own
• MCP tools let an AI agent work the review queue. Read access is on by default and write access is opt-in per tool; no tool can dismiss a slate, move a cut or export an unchecked field

Try it in two minutes

1. Run a pre-loaded roll, or upload a clip that opens on a slate
2. See the roll's timeline: which frames the detector picked, what the model read, where each clap is and where each take is cut
3. Confirm or correct the fields the model was unsure of, then export the takes and the manifest

1. Trace

An AI agent (Claude on Amazon Bedrock, using native tool calling in a loop written in Go) picks one lookup at a time based on what the last one showed: the license library, the owners of the recording and the song, sample detection, territory and usage coverage, and prior precedent. When it finds a sample, it goes and traces that record's owners too. Every tool it has is read-only.

2. Stop

The agent stops when it has what it needs, or at a hard limit of 8 tool calls. A chain of samples too deep to finish is marked incomplete and handed to a person, along with what the agent still wanted to check. It is never asked to guess a conclusion.

3. Check

Plain code, not the model, re-reads the evidence. Any owner it couldn't identify, territory or use not covered, check the agent skipped, or matching refusal on file sends the request to a person. The agent's own opinion can make the result stricter, never looser.

4. Decide

A rights coordinator reads the whole trail and the rules' verdict, then approves (with conditions) or denies. That is the only place anything is actually cleared.

Why it holds up in production

• It researches, it doesn't decide: the agent looks things up and reports what it found. Whether a track is cleared is decided by fixed rules and then by a person, never by the model
• The agent chooses its own next step inside hard walls: six read-only lookups (read-only down to the database permissions), an 8-call cap and a time limit. Tests prove the tool set can't write and the cap can't be exceeded
• The rules trust evidence, not prose: they recompute every work in scope from the recorded lookups and fail anything unverified, so the agent can't talk its way to a clear
• Full audit trail: every tool call with its input, its result and the agent's stated reason for it, laid out step by step with the branches it followed
• MCP tools let an outside AI agent work the review queue. Read access is on by default; starting an investigation (it costs model calls) and approving or denying are opt-in per tool, budgeted and logged

Try it in two minutes

1. Run an example: an in-house track that's already cleared, a hidden 1978 melody to trace, an owner nobody can find, a territory gap, a past refusal, or a chain of samples too deep for the cap
2. Watch the trail build step by step: where the agent branched and why, then how the fixed rules judged its evidence
3. Approve or deny as the coordinator, or write your own request for any track in the catalog

1. Note

The artist types a note in Blender's light panel. Only the note and the selected light's own settings are sent; nothing else from the scene, and no images.

2. Interpret

One bounded model call (Claude on Amazon Bedrock, forced to a fixed tool schema) turns the note into proposed values for that light's controls. It refuses notes about placement or taste, like "move the key left" or "make it more cinematic".

3. Propose

Go code clamps every value to the ranges Blender actually accepts and reports each correction. The artist sees current and proposed values side by side, with a one-line reason and a confidence.

4. Apply

Nothing changes until the artist clicks Apply, and then it is one undo step. Rows can be unticked or edited first, or the whole proposal discarded. The outcome is logged either way.

Why it holds up in production

• Nothing is ever applied automatically: the artist reviews a diff and applies it as one undo step, edits it, or discards it
• The model only proposes the light's own controls, and Go code clamps them to Blender's real ranges, checked against five Blender releases from 4.2 to 5.2
• Physical snoots (real geometry that resizes with the light) and a gallery of 24 gobos for people who would rather pick by eye than describe a look. Both work with no account or internet
• Cost guardrails on the backend: hashed per-person keys, monthly caps, a global daily cap, a kill switch that trips on its own, and an audit trail of every note and outcome

Try it in two minutes

1. Install the plugin in Blender 4.2 or newer and select a spot or area light
2. Add a snoot or pick a gobo from the gallery; no setup needed
3. For the notes assistant, run make self-host to deploy your own backend, then type a note like "snoot it down, keep it warm"