Build and Prove

Configure a Platform service, test its behavior, and release selected versions with clear acceptance criteria and a recovery plan.

Follow this path to configure a service, test the workflow, and release selected versions. You need a test workspace, permitted synthetic data, and an implementation owner who can confirm which tools and channels are enabled.

Promotion is an explicit decision based on reviewed evidence; recovery also checks external effects.

Build

Agree on the workflow before configuring the agent. Write a patient arc with the user's request, source data, decision branches, permitted actions, completion criteria, and handoff owner. Have the customer workflow owner review the expected behavior and exceptions. Use synthetic examples to turn those decisions into test cases.

Console groups authoring under Build: Agents, Context Graphs, Tools, Services, and Channels. Visibility and permissions depend on the workspace. Use the corresponding contracts when automating the same task.

1. Confirm credentials and workspace access.

2. Configure the agent and Context Graph. Publish graph changes through the supported API or Agent Forge; Console graph pages provide version inspection and JSON export. Identify which tools can read data or change an external system, and use test targets for the first run.

3. Bind the agent and graph in a service. Read back the selected versions and field-specific configuration. A service version set does not isolate all data or external effects.

4. Choose the supported conversation path. Managed channels require a provisioned binding. Console Channels forms begin the managed setup process; submitting a form does not provision the channel.

If a tool needs an application value supplied when the conversation starts, follow Pass Context to Tool Parameters to declare the service schema and bind the parameter in the graph. Keep that input separate from identity bindings and choose the tool's result-retention policy deliberately.

Evaluate

Console's Evaluate area includes Playground, Runs, Simulations, Case Library, and Suites. Choose your first check:

• First Console Conversation walks through a browser text session with your configured service, including readiness errors and inspection controls.

• First Verified Conversation provides a runnable SDK project, durable-answer verification, a rejected-request exercise, and cleanup. Start locally without credentials, then use its provisioned mode to test your service.

For a graph or channel change, use Playground and the applicable simulation workflow. Cover these cases from the approved arc:

• The normal path reaches the expected result.

• Missing or stale data triggers the agreed recovery or handoff.

• An existing request is handled without duplicating it.

• An unauthorized or rejected action follows the agreed failure path.

• A human handoff reaches the right owner with the required context.

Record the configuration, input, expected outcome, observed result, and failures for each case. Verify external changes separately with Verify an Integration Action. Simulation success does not establish production delivery or deterministic future output.

Promote and Recover

Use Version Sets & Promotion to compare the candidate with the current release and retain the previous selection for rollback. Prefer explicit component versions for a reproducible release; an unpinned version can resolve newer configuration later.

Before promotion, record who reviewed the evidence, which channel and integration checks ran, and how to recover if the new behavior fails. After promotion, inspect a permitted test run through Runs. Rolling back configuration does not undo external mutations that already completed; reconcile those through the owning integration.