The short answer

AgentPlat’s first-execution path starts with a deterministic mock and does not need a database or model key. A real invocation requires an explicit provider, model and server-side credential. Ephemeral execution does not automatically create persistent Rooms or approval controls.

Use deterministic output to check the setup

The first-execution guide uses the framework and mock runtime from a source checkout. The example checks that the selected local composition can build and run before introducing a remote provider.

Follow the prerequisites and commands for that checkout. If the example fails, retain the build or runtime error. Adding a model key at that point introduces another dependency without explaining whether the original package composition works.

Make provider selection explicit

The guide demonstrates a server-side AgentPlat.ask call with deliberately chosen provider, model and credentials. Once connected, the provider receives the prompt, output is no longer deterministic and provider charges may apply.

For an illustrative document-summary experiment, use synthetic text first. Record the model and adapter version with the result. A different response is not necessarily an integration failure; distinguish connection errors, invalid configuration and model variability in the observation.

Keep credentials at the application boundary

The provider discovery reference makes the adopting organization responsible for provider selection and credential management. There is no shared AgentPlat API-key store to populate.

Your application should obtain secrets through its server-side deployment configuration and expose only the intended user operation. Avoid sending a provider credential to the browser just because a minimal example shows a compact invocation. The example's brevity is not a deployment architecture.

Know what an ephemeral call leaves out

The documented ask and quickRun paths do not create durable Rooms, approvals or protected-action controls. Returning an answer therefore says little about what remains after the process or session ends.

If the next requirement is a retained draft, review decision or shared task, move to the persistent collaboration path. Add that work model because the application needs it, rather than assuming a session transcript already supplies equivalent records.

Promote the experiment one boundary at a time

Check local execution, then provider invocation, then the persistence or control requirement that motivates the next step. The incremental integration guide provides the broader progression.

A useful result records which step passed and its limits: the deterministic build ran, the chosen provider answered, or the application retained a specific artifact. These are separate observations and should stay separate when estimating the remaining implementation work.

Sources and further reading

Documentation reviewed . Consult the linked documentation for current implementation details.