Execution Profiles

Initiative 3 adds ExecutionProfile — the canonical execution contract for managed execution. Hospitals don't approve API keys; they approve execution configurations: "GPT-5 Structured Clinical," "GPT-5 Fast Triage," "Claude Long Context Review." Those are Execution Profiles — a reusable enterprise asset, independent of whose provider account backs them.

Why this is a separate concept from Provider Connection

A Provider Connection answers exactly one question: whose account and credentials should be used? It deliberately knows nothing about models, temperature, timeouts, or retries.

An ExecutionProfile answers a different question entirely: when this agent executes, use this provider, this model, these inference parameters, these timeout/retry rules, these output constraints. Those concerns must never live inside ProviderConnection — see that page's "Four separate concepts" table for the full picture.

RegisteredAgent  →  ExecutionProfile  →  ProviderConnection  →  Adapter  →  Provider  →  Runtime Control
     "what may           "how should              "whose                "how CARC       (the model)     (evidence/
    this agent do?"      it execute?"          credentials?"          talks to it")                       policy/risk)

Nothing downstream of the Adapter changes — Execution Profiles slot into the exact same evidence/policy/risk/Decision Controller pipeline every other Agent Run goes through.

Fields

An ExecutionProfile contains execution configuration only — never a credential.

Field	Notes
provider, adapter_id, provider_connection_id	The provider protocol, the Adapter Registry entry, and the tenant-owned connection this profile executes through. Not validated for existence until managed execution is attempted.
model, model_version	Required (model); wired end-to-end into the OpenAI adapter today.
temperature, top_p, reasoning_level, response_format	Stored, returned, and shape-validated. Not yet applied by any provider adapter's execute() — see Configuration and security considerations below.
max_output_tokens, timeout_ms	Wired end-to-end into the OpenAI adapter's request.
structured_output_enabled, tool_calling_enabled, streaming_enabled	Capability toggles. Stored and returned; not yet enforced against the adapter's actual capabilities.
retry_policy, retry_attempts, retry_backoff_ms	Stored and shape-validated. Not yet applied — a managed execution still makes exactly one attempt.
validation_policy	Reserved for future output-validation strictness configuration. Not yet enforced.
status	draft | active | disabled — see Lifecycle.

Lifecycle

draft ──activate──> active ──disable──> disabled ──activate──> active

Simpler than ProviderConnection's lifecycle deliberately — a profile is pure configuration data, never a credential, so there is no live validation step. Only active profiles may serve managed execution.

The managed-execution resolution order

POST /runtime/agents/:agentId/execute resolves, in strict order:

1. The agent exists under the resolved tenant.
2. The agent is active/executable.
3. The agent has an execution_profile_id.
4. The ExecutionProfile exists under the same tenant.
5. The profile is active.
6. The profile has an adapter_id.
7. The profile has a provider_connection_id.
8. The adapter exists.
9. The adapter is available.
10. The ProviderConnection exists under the same tenant.
11. The connection is valid.
12. The profile's provider matches the connection's provider.
13. The adapter's provider matches the profile's provider.
14. The adapter supports the requested task type/execution mode.
15. The agent is allowed to perform the requested task.
16. The profile has a model configured.
17. The connection's endpoint, if set, is well-formed.
18. The credential can be resolved from the CredentialStore.
19. A managed-execution implementation exists for the resolved provider.

Any failure returns a 409 (configuration mismatch) or a tenant-scoped 404 (missing resource) — never a silent substitution of a different profile, adapter, connection, or Giggle's own credentials. Steps 4 and 10 are what make cross-tenant resource reuse structurally unreachable: both the profile and the connection are always looked up scoped to the calling agent's own tenant_id — there is no fallback branch anywhere in the resolver that reaches for a different tenant's resources.

Backward compatibility

Agents registered before Initiative 3 (or by a caller still using the old shape) set adapter_id + provider_connection_id directly. That shape is still accepted: if a caller submits both without an execution_profile_id, the engine automatically creates and activates an ExecutionProfile on their behalf, tagged metadata: { auto_migrated: true }. No existing integration breaks. RegisteredAgent.adapter_id itself is kept as a deprecated, display-only field — ManagedExecutionResolver always reads the adapter through the ExecutionProfile now, never from the agent directly. RegisteredAgent.provider_connection_id no longer exists as a stored field at all.

Configuration and security considerations

• ExecutionProfile holds no credential — there is no field on this type that could hold one, unlike ProviderConnection.
• Only model, model_version, max_output_tokens, and timeout_ms are currently wired into the OpenAI adapter's actual request. temperature, top_p, reasoning_level, response_format, structured_output_enabled, tool_calling_enabled, streaming_enabled, and the retry_*/validation_policy fields are accepted, validated, and returned by the API today, but not yet applied at execution time — this is real, tracked follow-up work, not silently dropped.
• Deleting an ExecutionProfile is rejected (409) while any agent still references it.

APIs

POST   /runtime/execution-profiles
GET    /runtime/execution-profiles
GET    /runtime/execution-profiles/{id}
PATCH  /runtime/execution-profiles/{id}
DELETE /runtime/execution-profiles/{id}
POST   /runtime/execution-profiles/{id}/activate
POST   /runtime/execution-profiles/{id}/disable

SDK usage

const connection = await runtime.createProviderConnection({
  provider: "openai",
  displayName: "Acme Health — OpenAI Production",
  credential: process.env.ACME_OPENAI_API_KEY!,
});
await runtime.validateProviderConnection(connection.connection_id);

const profile = await runtime.createExecutionProfile({
  displayName: "GPT-5 Structured Clinical",
  provider: "openai",
  adapterId: "openai-responses-adapter",
  providerConnectionId: connection.connection_id,
  model: "gpt-5",
  temperature: 0.2,
  maxOutputTokens: 2048,
});
await runtime.activateExecutionProfile(profile.profile_id);

await runtime.updateAgent("acme-discharge-summary-agent", {
  executionProfileId: profile.profile_id,
});

const result = await runtime.executeRegisteredAgent("acme-discharge-summary-agent", {
  caseId: "case_demo_001",
  taskType: "discharge_summary",
  clinicalContext,
  sourceReferences,
});

See SDK Guide and REST API Guide for full reference, and Provider Connections for the credential/ownership half of this architecture.