The LaunchAI Studio builds an AI agent from a conversation and a demo. You describe the job by voice or text and show the parts that are faster to show. The Studio performs each step live on your real application, and you approve or correct it before the next step begins. When you finish, the agent is validated and its documentation already exists.
What the Studio is
The Studio is the part of LaunchAI ADK where agents are built. It replaces two things at once: the prompt, and the developer who would otherwise translate a clerk's knowledge into code. Its raw material is the knowledge of the person who does the job today. Its output is a validated workflow, the rules and tables that workflow reads, and a written procedure with a screenshot for every step.
The problem it solves is older than AI. In 1966 Michael Polanyi opened The Tacit Dimension with the observation that “we can know more than we can tell.” In 2014 the economist David Autor named the consequence Polanyi's paradox: the tasks people perform without being able to state the rules are the tasks automation struggles to reach. A credit analyst knows which of three limit fields to fill, which references count, and which scans hide the requested amount in the margin. Ask for a written procedure and half of that never reaches the page.
The Tacit Dimension. Polanyi: we know more than we can tell.
Pygmalion. An early system that learned from a person performing a task.
Watch What I Do. The MIT Press volume that collected programming by demonstration.
Polanyi's paradox. Autor: what we can't state, we struggle to automate.
Both channels. Say it, show it, and the machine proves it understood on the real screen, before anything counts.
The problem with prompts
A prompt is a paragraph. A back-office job is a sequence of screens with decisions between them. The paragraph fails in two places.
Too obvious to write down: blank fields get skipped, a bank reference older than ninety days does not count, anything over the approval limit goes to the manager. The model fills the gap with a guess.
Which of three similar fields on a crowded form. Which tab, after which popup. A person learns these by watching. A prompt has no way to show them.
A prompt also hides its interpretation until the agent acts on it. The Studio reverses the order: it shows you what it understood, on the real screen, before anything counts.
A Studio session
State the job, show what is faster to show, answer only what matters, and approve step by step. In practice the moves break into nine steps.
Out loud or typed, the way you would brief a new hire on day one: what arrives, what you do with it, where the result goes, and who hears about it.
Open the application and do the step. The Studio watches the screen and turns what it saw into proposed steps.
The Studio asks only when the answer changes what the agent does (which window, which column, what to do with a blank), and never asks for something you already told it.
Each step arrives in plain language before it runs: the application, the screen, the field, the value, and what the screen should show when the step is done.
The Studio performs the step on the live application: opens it, navigates, clicks, types, reads the value.
An approved step is saved with its screenshot and a short clip. A corrected step is performed again while you watch.
Rules, tables, review steps, and variables appear as you speak them (see Captured as you speak, below).
The map grows one box per approved step, with a labeled branch for every decision and review outcome.
The finished draft moves to the workflow builder, where versions and approvals live.
During a session
You work with three things at once: the conversation, the live application on your own machine, and the map, which gains a box each time you approve a step.
When you mention a rule, it appears in Rules and Tables in plain language, where you can read it back and fix the wording on the spot.
The Studio proposes all of that. Your job is to know the work and to say “yes” or “not quite.”
Captured as you speak
The Studio listens for structure.
“Never approve more than the ceiling for their score band.”
RecordsAn exact rule
Lives inRules, in plain language, versioned
“Distributors go in credit group DIST, manufacturers in OEM.”
RecordsA lookup table
Lives inTables, read by the agent at run time
“If the bank reference hasn't come back, send it to me.”
RecordsA human review step with approved and rejected branches
Lives inThe workflow map, as its own box
The applicant and amount you used while demonstrating
RecordsNamed variables, such as {{customer_name}} and {{requested_limit}}
Lives inThe step, so tomorrow's applicant runs through the same procedure
A spoken hard rule becomes a rule the agent applies exactly, with no model consulted. Fuzzy words are where rules go wrong, so the Studio pushes them to numbers: “weak references,” “a big order,” and “recent” each earn a question, because each one changes which branch the agent takes. How exact rules execute, and why money never goes down the model path: Dual-Path Rule Engine.
Short lookups are dictated. Long ones arrive as the spreadsheet the team already keeps: import it, check the preview, and the agent reads the table live at every run. Whoever owns the table can change a row without touching the workflow, and the next run uses the new row.
Any sentence that hands a decision to a person becomes a review step with its own branches. The Studio asks what happens after a rejection, because a rejected application has to end somewhere on the map. Placement, assignment, and the reviewer's screen: Human review.
Every value typed or read during the demonstration is a sample. The legal name typed on Tuesday becomes {{customer_name}}, and the limit becomes {{requested_limit}}. To check a finished step, read it: a step that names a specific customer, amount, or date in plain text is a hard-coded value, and it is a correction, not a feature.
Questions
A Studio that asked about everything would be a form. A Studio that asked about nothing would guess.
The Studio never asks for something you already said, something it can read on the screen, or a preference that changes nothing the agent does. A contradiction is different. If a new sentence conflicts with an earlier rule, the two cannot both run, which is exactly the condition that earns a question.
| The Studio asks when | Example | Why the answer changes the agent |
|---|---|---|
| Two windows or companies could be meant | Two Dynamics 365 legal entities are open | The step writes to one company's ledger, not the other's |
| A target is vague | “Enter the date,” on a form with an order date, a ship date, and a due date | Each date drives a different step downstream |
| An input can be blank | The applicant left the trade references section empty | The agent needs a branch, not a crash |
| “Done” is unclear | Is the step done when Save is pressed, or when the record reloads? | The verify check depends on it |
| A condition is fuzzy | “Flag anything unusually large” | A branch needs a number |
| A decision has no owner | “Someone should look at big ones” | A review step needs a reviewer and a threshold |
Worked example
A new customer cannot ship on terms until it is done, so every day of backlog is a day of held orders.
Here is the chain a credit analyst teaches in one sitting, as the Studio records it. Handled today by sales, estimating, and customer service staff. The thresholds are this company's own policy.
Open the new application from the shared credit mailbox. Read the legal name, requested limit, trade references, bank reference, and the D-U-N-S number when there is one.
In Dynamics 365 Finance, open Accounts receivable > Customers > All customers and find the account, or confirm it is new.
Pull the applicant's report from the credit bureau portal the company subscribes to. Read the score band.
The proposed limit is the lesser of the requested limit and the ceiling for that score band, from the ceilings table. Fewer than two trade references paying within terms, or a proposed limit above $50,000, goes to review.
The credit manager sees the application beside the proposed record, then approves, rejects with a reason, or changes the limit.
On the Credit and collections FastTab, enter Credit limit in customer's currency, Last review date, Next scheduled review date (twelve months out), and the credit management group from the lookup table.
Email the salesperson the decision and the limit.
Field names follow Microsoft's Credit management documentation; screens vary by version and configuration.
Behind the chain
The D-U-N-S number is a nine-digit identifier that Dun & Bradstreet assigns to each business location, and many suppliers ask for it on credit applications. That is why the analyst expected it on every form, and why its absence on the third sample mattered: the Studio pointed at the blank, and a new branch sprouted on the map.
| Step | Taught by | What the Studio captured |
|---|---|---|
| 1 | Said, then shown in the mailbox | The mailbox and folder; variables {{customer_name}}, {{requested_limit}}, {{trade_references}}, {{bank_reference}}, {{duns_number}} |
| 2 | Shown | The navigation route; a branch for existing and new accounts |
| 3 | Shown in the bureau portal | The route to the report; variable {{score_band}} |
| 4 | Said | Two exact rules and a ceilings table |
| 5 | Said: “send it to me” | A review step for the credit manager, with approved, rejected, and corrected outcomes |
| 6 | Shown | The FastTab, four fields, and the date arithmetic for the next review |
| 7 | Said | A notification step to the salesperson named on the application |
Rules and tables
The ceilings below are illustrative; a real company dictates or imports its own.
| Score band | Ceiling (illustrative) |
|---|---|
| 1, lowest risk | $75,000 |
| 2 | $40,000 |
| 3 | $15,000 |
| 4 | $5,000 |
| 5, highest risk | $0 (cash in advance) |
“The proposed limit is the lesser of the requested limit and the ceiling for that score band.”
proposed = min({{requested_limit}}, ceiling[{{score_band}}])“Fewer than two trade references paying within terms, or a proposed limit above $50,000, goes to review.”
refs_within_terms < 2 OR proposed > 50,000 → review| Customer type | D365 credit group |
|---|---|
| Distributor | DIST |
| Manufacturer | OEM |
Same rules, three paths
The same procedure, three illustrative applicants, three different paths.
For applicant A, processed on September 28, 2026. Nobody typed either date during the demonstration. The Studio turned “twelve months out” into arithmetic on the run date.
A month later
Seasonal customers ask for a higher limit before their busy quarter. Dynamics 365 handles that with temporary credit limits, entered through Credit management > Credit limit adjustments > Credit limit adjustments, which override the standing limit for a defined period.
The analyst opens the Studio, says that seasonal requests with a stated end date go to a temporary limit instead of the standing one, and shows the adjustments page once. The Studio adds the decision and the new action, validates both on screen, and redraws the map. The other seven steps are untouched.
Validation
Validation is the loop from the session: the Studio restates, performs, and waits for your approval, one step at a time. It exists because an instruction that was understood and an instruction that was merely acknowledged look identical until something goes wrong.
Validation runs on live software. When the Studio performs step 6, it writes to a real customer record. Teach on a record you are ready to process, or in a test environment if you keep one, and watch every step that writes.
What surfaced
Validation drags into daylight the failures that normally wait for production. In the credit session, five did.
Some applications arrive as scans, with the requested limit handwritten in the margin.
“Put in the limit,” on a FastTab that shows Credit limit in customer's currency, Eligible credit limit, and Total credit limit. The Studio asked which.
Two controls with the same label on one form. The Studio showed which one it would press before pressing it.
“If the references look weak” became “fewer than two trade references paying within terms.”
“The D-U-N-S number is always there.” The third sample had none.
Controls during validation
When a step fails during teaching
The Studio shows what it expected on the screen and what it found. Three causes cover most failures, and each has its own fix.
Stopping is not rolling back the ERP. If the Studio saved a credit limit in Dynamics 365 and you then stop the session, the limit stays saved, and the record shows which steps committed. Correct the value in the ERP or teach the correction as a step.
Choosing the record
Bring the scan, the form with a blank, and the customer who formats everything differently alongside the clean sample. The messy sample is where the questions come from, and each question answered in the Studio is one the agent will not face alone later.
For a process that runs monthly, teach during the month's real cycle, so the screens show real balances and real exceptions.
Other ways in
A session can start from, or mix in, a screen recording, a stack of screenshots, an existing SOP, plain-English notes, or Python.
| Input | Best for | What still happens |
|---|---|---|
| Screen recording | A procedure the expert performs better than they explain | Every step is still performed live and approved |
| Screenshots | Screens you cannot open during the session | The live step is validated when the application is available |
| Existing SOP | A procedure that is already written down | Gaps in the SOP come back as questions |
| Plain-English notes | Rules and exceptions collected over years | Each rule is captured as a rule, each lookup as a table |
| Python | Code the team already trusts | It attaches to a step as a code hook |
Automatic SOP documentation
Ask for the written procedure behind a credit decision and you get a shrug, or a binder tab last updated before the ERP upgrade. When that person leaves, the process leaves with them.
In the Studio, documentation is a by-product of building. It contains:
Every step was performed and approved before it was written down, so the document records what happened, not what someone believes happens. It is the agent, drawn: change a step and the chart changes. Every revision is kept, so last quarter's procedure can sit beside this quarter's.
Export it as a PDF, a slide deck, or a shareable page, or email it from the builder. Auditors get the step, the screenshot, and the rule. New hires learn the job from pictures. The author, a year later, recalls the route through a portal the vendor has since redesigned.
After the session
The Studio hands off at the moment you submit. Each component picks up one part of the agent's life.
Governance and security
The agent will later act alone. The Studio treats building it that way.
The person who builds a workflow can be barred from approving it for production, so a second name signs every version.
The Studio can do only what the signed-in user can do in each application.
The recommended posture is to stay logged in, so most sessions never show a sign-in screen. Where a credential is unavoidable, it comes from the vault and is masked in every screenshot and clip.
An approved version is read-only; changing it starts a new draft.
Model-path steps during validation send only the screen region being read to the model account your company configured. Exact-rule steps make no model call.
Python the Studio generates for a step is audited for forbidden imports and runs in a restricted interpreter. That is hardening, not a formal sandbox.
Measures
The Studio's output is a trustworthy agent, so the useful measures describe how much the session caught and how fast it converged.
| Measure | How to read it |
|---|---|
| Minutes to a validated draft | A session that runs far past an hour usually means the procedure itself was unsettled |
| Corrections per step | Repeated corrections on one step point to an ambiguous screen or an unstated rule |
| Questions the Studio asked | Each one is a rule that was missing from the written procedure |
| Hard-coded values caught | Samples that became variables; zero on a long workflow deserves a second look |
| Review steps and their reasons | Every review should trace to a policy, not to nervousness |
| Days from submitted to approved | A long wait usually means the approver has questions the documentation did not answer |
| Supervised cycles to acceptance | Counted in cycles of the work, not days |
| Revisions per quarter after go-live, by cause | Vendor changes, policy changes, and missed logic call for different fixes |
Tradeoffs
LaunchAI can build any agent a person can teach, through the same screens the person uses. Other build methods cover a subset of that, and a narrower method can make sense for its subset.
Two tradeoffs belong to the Studio itself. Validation touches live systems, which buys realism at the cost of care on every step that writes. And conversation shortens the build, not the proving: the supervised cycles still run at the pace of the work itself.
| Build method | The subset it covers well | When it can make sense | What the Studio adds |
|---|---|---|---|
| Code-first agent frameworks | Agents engineers write over APIs | An engineering team already owns the process and its APIs | A builder for the person who knows the work; Python still fits as a hook on any step |
| RPA recorders | Replaying clicks on stable screens | The company already holds licenses and developers | Intent, rules, review steps, and live validation instead of a replay |
| Prompts to a chat or computer-use assistant | One-off personal tasks | The task runs once and nothing is posted | Validation, versions, documentation, and a procedure that runs the same way tomorrow |
Questions
The person who does the job. They know the exceptions, the blank fields, and the customer who formats everything differently. IT's role is enrolling the machine and setting permissions. The builder keeps ownership afterward and makes changes by re-showing the step that moved.
Most first agents are built in under an hour. That clock is the one demonstration compresses. The second clock cannot be compressed: a supervised period of real cycles, watched before the agent runs alone. Measure it in cycles of the work: a monthly process needs months.
No. Python is an optional input for teams that already have code worth reusing. Rules you speak become exact rules without it.
Correct it when you notice, and watch the corrected step run. If you notice after approving, change the step in a new revision; every revision is kept, so the earlier one stays on record.
Describe it now and show it when it arrives. A spoken exception becomes a branch; if you cannot demonstrate it yet, route it to a review step so a person handles it until a real example lets you validate the branch on screen.
The generated documentation: the flowchart, the plain-language step in each box, the screenshot and clip from validation, and every rule and table where it is used. The approver signs off on what the agent was seen to do, not on a description of what it should do.
No prompts. No babysitting. No dumb questions.