Patterns

Use Studio as the feedback loop while building Runiq features.

The pattern is simple: define a focused runtime component in .NET, register it, open Studio, test it, inspect the runtime details, and then adjust the code.

Recommended development flow

Start with one focused agent
Attach one typed tool
Register both in the ASP.NET Core app
Open Studio
Confirm the agent and tool are visible
Run a realistic prompt
Inspect tool calls and final output
Add workflows or Context Spaces only when needed

Studio helps keep growth controlled because every new runtime component becomes visible: agents, tools, workflows, context sources, skills, and execution events.

The sample apps are useful because they are small enough to inspect end to end. Treat them as examples of what Studio can reveal, not as products to copy directly. Your own application should keep its domain names, services, and workflow stages.

Use Studio before building custom UI

Do not build a custom product UI just to discover whether the runtime works.

First prove the runtime behavior in Studio:

Can the agent answer?
Can it call the tool?
Can the tool execute with the expected input?
Does the workflow produce the right final output?
Does context retrieval find the right source material?

After that, build your app-specific UI on top of behavior you already inspected.

That sequence also keeps product UI decisions separate from runtime debugging. Studio can prove that the agent, tool, workflow, or Context Space behaves correctly before the feature is embedded into a customer-facing screen.

Keep Studio developer-focused

Studio is not the customer-facing product UI.

It is the developer surface for:

• local testing,
• prompt and instruction iteration,
• tool contract validation,
• workflow debugging,
• Context Space inspection,
• runtime metadata checks.

Your production app can expose a different user experience while Runiq Studio remains the embedded developer surface.