Direct SDK Integration Docs

Use the SDK when

• your orchestration is framework-independent or already custom
• you want to call execute and commit directly
• you want full control over request shape, trace continuity, and runtime context
• you do not want an adapter deciding how tool calls map into runtime requests

Use an adapter instead when

Choose an adapter when your application is already centered on a specific tool surface and you want Admissible to sit inside that existing flow.

Already in OpenAI or LangChain? OpenAI docs or LangChain docs.

BaselineClient

Creates the direct API client and keeps transport details like base URL, auth, timeout, and default headers out of the rest of your integration code.

• takes baseUrl, apiKey, timeoutMs, defaultHeaders, and userAgent
• stays framework-independent
• does not change your orchestration or request builders

client.execute(...)

Sends an explicit execute request to the runtime and returns the immediate operation response for the proposed action.

• call this first when the system is deciding whether an action should proceed
• inspect result, status, message, nextAction, continuation, and operation.id on the returned result
• establishes the operation id you carry into any later commit step

client.getOperation(...)

Fetches the current operation status when the immediate response tells you to poll, await approval, or inspect the latest continuation state.

• use the operation.id from execute or commit responses as input
• inspect approval, continuation, retry, rollback, and supersession state
• pair this with resolveOperationApproval when an operator needs to approve or deny an operation

client.commit(...)

Sends a commit request for the durable or irreversible state change after the earlier execute path has produced a supporting operation id.

• call this only after you have inspected the earlier execute result and decided the workflow should continue
• use this for durable writes, external effects, or irreversible actions
• requires an idempotencyKey and supports commitType, supportingOperationId, artifact, rollback, approval, and policy context
• keeps commit gating separate from execute evaluation

BaselineClientError

Represents a non-success API response with the HTTP status, parsed error data, and the runtime-facing code when one is available.

• use this for denied, deferred, or otherwise rejected API paths that return a non-2xx response
• inspect status, code, message, and data
• keep the parsed error payload because runtime reason data often lives there

What stays the same

• your application owns the orchestration flow
• your own tool runner or server logic stays yours
• your app decides when execute and commit calls happen
• your surrounding service architecture stays under your control

What changes

• you model actions explicitly in execute and commit requests
• you handle structured runtime decisions explicitly
• you preserve continuity between stages by carrying the returned operation data forward intentionally
• durable and irreversible paths may need explicit commit gating

Keep agent identity stable

Use a stable <InlineCode>agent.id</InlineCode> for the real capability or service role so runtime policy and audit data stay attributable.

Keep session continuity stable

Use a stable <InlineCode>session.id</InlineCode> for the user flow, workflow run, or job boundary that owns the decision sequence.

Carry the execute operation forward

Use <InlineCode>executeResponse.operation.id</InlineCode> as the continuity anchor by passing it into <InlineCode>supportingOperationId</InlineCode> on the later commit request. Without it, the commit path loses the explicit supporting context from the earlier execute stage.

Keep context explicit

Environment, target, intent, request metadata, approval context, and policy context should stay coherent across the full multi-step flow instead of being inferred implicitly.

Server-side orchestrators

Use the SDK when a backend service or control plane already owns the multi-step workflow and just needs direct runtime decisions.

Custom tool runners

Map your own tool runner or action dispatcher into explicit execute and commit requests instead of trying to force it into an adapter abstraction.

Irreversible-action review flows

Run the proposal or inspection step first, then gate the later commit on the earlier operation response and supporting operation id when the workflow reaches a durable or irreversible boundary.

Multi-step continuity

Carry session, request, and operation continuity through queue or job boundaries so later stages can preserve decision context instead of collapsing multiple runtime stages into one assumption.

BaselineClient

new BaselineClient({
  baseUrl,
  apiKey,
  timeoutMs,
  defaultHeaders,
  userAgent,
})

Creates the direct SDK client for execute and commit API calls.

• baseUrl and apiKey are required
• timeoutMs defaults to 15000
• defaultHeaders and userAgent let you carry service-level metadata into the request

client.execute(...)

client.execute({
  requestId,
  agent,
  session,
  action,
  intent,
  constraints,
  metadata,
})

Sends an execute request and returns the immediate operation response.

• use this when the system is evaluating whether an action should proceed
• inspect result, status, nextAction.type, and operation.id on the response

client.commit(...)

client.commit(
  {
    requestId,
    agent,
    session,
    proposedCommit,
    commitType,
    supportingOperationId,
  },
  {
    idempotencyKey,
  },
)

Sends a commit request for a durable or irreversible state change.

• use this when a later state change needs explicit commit gating
• keep supportingOperationId tied to the earlier execute path
• add artifact, rollback, approval, or policy context when the commit path needs it and always pass an explicit idempotencyKey

client.getOperation(...)

client.getOperation(operationId)

Fetches the full status view for an operation that is still processing, pending approval, or otherwise needs follow-up.

• use the operation id returned by execute or commit
• inspect approval, continuation, retry, rollback, and supersession state
• use this before operator follow-up when nextAction tells you to check status

client.resolveOperationApproval(...)

client.resolveOperationApproval(operationId, {
  decision: "approve" | "deny",
  comment,
  reviewerNotes,
  reason,
})

Submits an operator approval or denial decision for an operation that is waiting on approval.

• call this only after getOperation shows approval.state === pending
• decision must be approve or deny
• follow with getOperation when you need the updated operation state

BaselineClientError

error.status
error.code
error.message
error.data

Represents a non-success API response from the runtime.

• status is the HTTP status
• code is the parsed runtime-facing error code when one is present
• data preserves the parsed response body for deeper inspection

BaselineTimeoutError

error.timeoutMs

Represents a client-side timeout at the SDK transport layer.

• treat this as transport behavior, not a runtime decision
• choose retry behavior based on your own idempotency and workflow model