Agent guide / the working agreement
A job to run.
A limit to respect.
Use Symbioza for containerized GPU work that has a defined end and files to return. Your agent prepares the job; Symbioza manages the compute.
The right fit
Send a workload.
Skip the machine hunt.
Good for finite GPU jobs
Training, evaluation and batch inference with your container, command, accessible data and a clear output contract.
Choose a different tool for live services
This workflow is not a persistent web server, an interactive workstation or a promise of low-latency inference. It is a job that runs and ends.
Declare genuine compatibility requirements. Your agent does not need to choose a provider or shop for a GPU.
From request to result
Make each step explicit.
Use the tools exposed by your connected client as the current schema authority.
| Tool | What your agent should do |
|---|---|
| describeDataset | Inspect a reachable dataset URL and prepare its metadata. Check that the URL is authorized and suitable for the job. |
| estimateExecutionNO COMPUTE BOOKED | Send the intended job spec. Show the estimate, spending limit and any missing requirements. An estimate is not a fixed price or a reservation. |
| submitJobPAID STEP | Review the job and limit with the user, then submit with the estimate digest and request identifier required by the tool. Prepaid credit is required. |
| getStatus / listJobs | Save the execution identifier and check progress later from the same account. The original client session does not need to stay open. |
| getArtifact | Inspect available files and delivery state. Download the outputs and verify their hashes. Check whether the charge is still provisional. |
| cancelJob | Request cancellation when needed. Used compute can still be charged, within the job’s total spending limit. |
Connector and submission details
Symbioza runs a containerized GPU job on a rented cloud machine under a hard dollar ceiling and collects available artifacts. An agent submits an image, a command and a budget through one MCP connector. Symbioza selects compute, runs the job and reports output delivery and billing separately. Recovery depends on job policy, available compute, remaining budget and compatible checkpoint support.
Connector: https://symbioza.dev/mcp.
Three required fields: image, command and budgetUsd. The gpu block is optional: every job runs on a GPU machine Symbioza sizes. Declare it only for gpu.minCudaVersion or an evidenced floor.
Send the reviewed spec with specDigest from the estimate and a stable clientRequestId. A changed spec needs a fresh estimate; reuse the request identifier only for retries of the same submission.
Do not ask the user to predict runtime. The limit is derived from the budget and booked machine rate, with a cap of 48 hours (172800 seconds). The budget usually binds first. maxRuntimeSeconds is optional and can set a shorter cap.
A retry on a larger machine must fit the remaining budgetUsd and job policy. With pinHost, no second machine is bought. Recovery and completion are not guaranteed.
Paid submission requires a prepaid balance. Top up after reviewing your estimate.
Clear boundaries
What the agent must keep straight.
The budget covers the whole job.
Retries share the same total spending limit. Recovery depends on policy, available compute and remaining budget; a job can stop without completing.
Checkpointing belongs in the workload.
Saving a checkpoint is only useful when your command can load the saved checkpoint. Do not describe every retry as a seamless resume.
Submission is separate from estimation.
Ask the user to review the job before spending. The review interaction depends on the MCP client; do not assume every client has the same approval screen.
Keep credentials out of the spec.
Job environment variables, commands, links and log tails may be retained. Never provide cloud-provider keys or SSH private keys. Read the Privacy notice before submitting data.
The next step is a price.
Connect your agent and ask for an estimate. An estimate is free and books no compute.