Every edit stacks up as a version, production runs against a pinned version, and the API connects the whole thing to your real systems. Keeping experimentation in Studio separate from what production points at is the core of running this safely.
Drafts and config versions
Edit an agent's settings and the next-numbered draft is created automatically; the moment you run, it is committed as a proper config version. Every version is kept, which makes experimenting safe.
How versions are created
- Change a node setting and the dropdown at the top switches to the next-numbered draft β start editing from Config #7 and you're on the Config #8 draft.
- Drafts save automatically. Keep editing; there's no save button to find.
- Press Run and the draft is committed as Config #8, and your cases are processed with it.
- When a version is committed, a change summary is recorded β "Extract step added", "Mode changed from Basic to Advanced".
- If you don't want a draft, discard it from the dropdown to go back to the previous version.
What the config dropdown can do
| Feature | What it does |
|---|---|
| Rename | Give a version a meaningful name β "Optimized for FedEx invoices", "Added decimal formatting" |
| Switch version | Select an earlier version and rerun documents against that point in time |
| Compare configs | Put the differences between two versions side by side |
| Aggregate | Combine the run results of several versions into one view |
Versions accumulate on their own, so experiment freely β and give the meaningful ones a name so your team can tell them apart.
"Versions stack up by themselves β experiment without hesitation, and name the meaningful ones so your team can recognize them."
The production rollout process
An agent running in production is called with a specific, validated config version.
Start from a baseline
Pin a well-tested config (say Config #12) in your API calls and go live with it.
Keep improving in Studio
Separately from production, keep editing schemas in Studio and building new versions (#13, #14, #15β¦). Production traffic still uses #12, so this is safe.
Validate the new version
Rerun your reviewed documents against the new version. They are compared against ground truth automatically, which tells you whether the new version is genuinely better.
Ship in batches
Don't deploy every version. Accumulate improvements and roll them out together (every four or five versions, for example). Bump the version number the API points at during a planned window, such as outside business hours.
Roll back if it goes wrong
If a new version performs worse, point the API's version number back β that's the whole rollback. You can also switch back in Studio at any time to reproduce the issue.
Don't over-optimize. A 0.01% accuracy gain isn't worth a production deployment. Wait until meaningful improvements have accumulated across several fields, and use Monitoring to compare versions.
"Production runs on a pinned version number, experiments live in Studio β ship once validated improvements have piled up."
Automating with the API
You can process documents in bulk through the API, with no screen involved β send documents from your internal systems and load the results into a database for a fully automated pipeline.
Where to find your API details
From the more (β―) menu at the top right of the agent screen, choose Use via API to open a step-by-step reference and code snippets for integrating this agent.
| Element | What it is |
|---|---|
| Agent ID Β· Config ID | The agent and config version to call. Pick the version you want in the Config ID selector (if no config version exists yet, run once to create one) |
| API key | Choose the key to use. The default key created at sign-up is connected already; issue and manage more in the Console |
| Code snippets | Step 1 upload a file β Step 2 create a job β Step 3 get the job. Toggle between cURL / Python and Linux / Windows and copy as is |
| Guide for AI assistants | The Copy code.md button β paste this into an AI coding assistant when you want it to write the integration |
| View docs | Jumps to the full Agents API specification |
The call flow
- Upload a file β upload the document to process and receive a file ID.
- Create a job β request processing with the agent ID, config ID, and file ID. Because you name a specific config version, your experiments in Studio never affect production.
- Get the job β query status and results by job ID. Each extracted value comes back with a confidence of
loworhigh. - (Optional) Get reviewed results β for work that needs human review, fetch only the results a reviewer has marked as reviewed and write those to your production database.
Jobs run through the API show up in the Monitoring job list (filter source: API), and Bring into agent pulls them onto the screen for review.
"The screen is where you build and review, the API is where you run it β an API call pinned to a version number is the core of stable operations."