Parts of an agent
| Concept | Meaning |
|---|---|
| Graph | Nodes (steps) and edges (control flow). One node is the entry where a run starts. |
| Nodes | Typically include LLM calls, branching, tool use, and outputs. |
| Tools | Named capabilities the model can invoke. Names and JSON Schemas must be registered on the service so the graph can reference them. |
| Inference providers | Agent nodes can run on multiple model backends, including OpenAI, Anthropic, Google, Groq, and Baseten. Depending on your deployment, plugin adapters can also route through AWS Bedrock or locally hosted models. |
| Validators | Optional output format rules (JSON Schema) attached to nodes to validate structured outputs. |
| Version | Published graphs have a version; API calls can pin agent_version or use the default active version. |
From authoring to agent_id
The easiest path to creating a new agent is to use a Sudoiq agent-builder—either in the product UI or through the agentservice CLI—to design, iterate, and publish your workflow. If you prefer, you can pair the CLI (for example agentservice agents modify) with your own coding agent or editor workflow: you maintain graph JSON/YAML locally while the CLI uploads and syncs with Sudoiq, so you can treat “building agents” as its own repeatable dev flow.
When published, the platform assigns a stable identifier — the agent_id (UUID) you pass to run_agent, execute, or webhooks.
Integrations only need the agent_id (and optional version) plus inputs (string slots, images, file references) to start execution.