Follow a Roth conversion example to see how Studio changes an application, uses relevant client information to draft a planning goal, and gives your team work to review.
“Add a required ‘Planning priority’ field to our intake form, and display it prominently at the beginning of the client report.”
This compares a basic prompt-and-reply pattern with Studio’s workflow. Chat interfaces can also have tools, memory and agentic behavior. The distinction is what executes behind the interface.
No application-editing tools connected.
Sent to the language model as a prompt.
Generates a reply from the context it receives.
“Add a required field to the intake and place its value beneath the report masthead.”
Someone still has to implement and check the suggestion.
Breaks the request into tasks and assigns it to specialized agents.
Inspects the current Roth intake, report structure and project requirements.
Finds where the change belongsAdds the required Planning priority field and connects its saved value to the report.
Uses tools to change the applicationChecks the changed form and report against what you requested.
Checks the required field and report placementChanges that need correction return for refinement.
Agents work through tools and security rules set by the organization. Security is granted based on least-privilege permissions.
A required intake field. A connected report section. Your team inspects, refines and tests the result.
Gather, Assemble and Check describe the roles illustrated here; the workflow can vary by task.
The How It Works animation shows a tool taking shape. This separate Northstar example explores how Studio adds a feature, drafts a planning goal, and supports your team’s review.
STUDIOIllustrative workspace“Add a required ‘Planning priority’ field to our intake form, and display it prominently at the beginning of the client report.”
“Add a button to draft or refine the goal using the selected client’s records.”
Select a client with records to suggest a goal. No client is selected while you shape the tool.
Empty until wording is saved. The saved value supplies this section.
Setup: Elliot Marlowe owns the application; Naomi Calder is the required launch reviewer in this example. Selection is not approval.
Interactive illustration. Northstar, its people, and its records are fictional. Numerical outputs are a historical sample, not new calculations. Technical annotations explain the workflow; they are not a production execution log.
Launch approval authorizes the application for the team to use. From there, each person reviews the reports they prepare.
The designated reviewers approve the application version—its functionality, calculation rules, output format and workflow.
Both launch decisions are required in this Roth example. Reviewer selection during setup is not approval.
The person using the approved application reviews the inputs, assumptions and resulting report before using it with a client.
The report does not return to the application’s launch reviewers each time it is created.
Inspect the work, the information boundaries and the decisions behind this example.
Follow a request through orchestration and tool actions. Match the resulting application changes to the intake field and report section.
Inspect tool permissions, the returned client context and the model request. Check how sensitive identifiers are excluded and access is scoped to the selected client.
Follow the second request against the existing application. Inspect saved project context, relevant checks and what happens when a change or check fails.
Confirm that the designated reviewers approved the application version released for the team. Check for an additional report-review step only when the firm includes one.
