agentserviceapi. The implementation package you import is agentsapi. The client class is AgentServiceAPIClient (from agentsapi import AgentServiceAPIClient). After pip install agentserviceapi you can also import the thin alias module agentserviceapi (same public symbols). Prefer from agentsapi import ... in application code.
Install
agentservice CLI bundles agentsapi as well. See CLI.
Authentication
Client API reference
The following lists public methods and namespaces onAgentServiceAPIClient. All HTTP-backed methods are async. Response types are Pydantic models from agentsapi.models (or nested packages such as agentsapi.models.tools) unless noted as plain dict or list.
Constructor and session
Run workflows
Shared execute parameters (where applicable):
agent_id, string_inputs, image_inputs, environment ("playground", "production", or "test"), metadata, optional tenant_id, optional extra_headers. Interactive methods also accept response_timeout (seconds; default from DEFAULT_INTERACTIVE_RUN_RESPONSE_TIMEOUT; use float("inf") where supported). See Timeouts and errors.
AgentInteractiveRun
Returned by execute_agent. await run and await run.get_response() both resolve to AgentGraphRunStatusResponse when the run finishes.
Webhooks and local tool helpers
Module helpers (same package):
extract_from_webhook, extract_basic_webhook_data — see Webhooks.
Workflow CRUD
Platform utilities
client.tools — server tool schemas
client.tests — stored test examples
See Evals, tests, and feedback.
client.graders — evaluators and comparisons
client.execution_feedback and client.agent_feedback
Same namespace exposed twice.
client.agent_execution_records
client.agent_validation — output validators
See Output validators.
client.agent_traffic_split
client.task_categorization
client.staged_agents
Exceptions and error codes
Import fromagentsapi: AgentServiceAPIException, AgentServiceAPITimeoutError, AgentServiceAPIConnectionError, AgentServiceAPIHTTPError, and constants such as ERROR_CODE_TOOL_RESPONSES_ALREADY_SUBMITTED. See Timeouts and errors.
Add a tool
Tools have two parts: a schema on the server (so the model knows the name and arguments) and, for interactive runs, a local async handler in your process. Registering schemas on Sudoiq is not something you repeat on every agent run. Do it once when your application starts (or whenever you deploy a new build that changes tools)—not inside the hot path that callsexecute_agent for each task. After a tool is registered, it stays on the platform until you explicitly delete it. If you change the name, description, or parameters later, register again with the revised schema so Sudoiq stays in sync with what the model and your handler implement.
1. Register the schema
2. Attach a handler and run
Handlers are usuallyasync def with signature (args: dict, agent_id: str, task_id: int) -> str. The client wraps each tool call so it can record errors, traces, and usage metrics alongside normal execution. When the model invokes a tool, args are exactly what the model supplied; agent_id and task_id identify the run that asked for it. That layout lets you register one handler and reuse it across many agents, while still branching on agent_id (or on values in args) when different workflows need different behavior.
Tests and feedback
Store test examples and record run feedback to drive quality and workflow iteration. See Evals, tests, and feedback.Integration patterns
For long-running or fully asynchronous backends, you can start runs and consume updates without holding a single long-lived connection—see Running agents when you need that split.Related
- Getting started
- Webhooks (optional integration style)
- Output validators