Choose a path · Honest comparison

Four roads through the agent forest.

The right tool depends on the work. Compare operating models first; compare provider names only after you know which model fits your job.

The crossroads

Begin with the operating model.

This comparison describes categories, not private evaluations of named companies. Capabilities change; the live contract remains the source for this API.

Raw model API

Maximum construction freedom

Best when your team wants to build orchestration, state, tools, retries, approvals, evaluation, and evidence itself.

IDE agent

Developer work inside a coding environment

Best when the primary job is changing a repository with a human developer present to review the work.

Enterprise suite

Prebuilt workflows inside an existing system

Best when identity, records, approvals, and business data already live in one vendor’s application family.

John Galt API

Bounded agent work over an API

Best when a service must expose real state, preserve an evidence receipt, control context, and run without an IDE session.

Plain-language decision table

Which road matches the work?

Need Strong first choice What you still manage
Custom inference inside your own product Raw model API State, tools, retries, safety, evaluation, billing, and receipts
Repository changes with an engineer reviewing IDE or coding agent Repository policy, review, CI, release, and production operations
Automation inside an established CRM or office suite Enterprise suite Vendor boundaries, configuration, governance, and portability
API-first work with observable progress and a completion receipt John Galt API Objective quality, customer approvals, and interpretation of the result

Fit, not folklore

Choose this API when its boundaries help you.

Trust improves when a product says where it fits—and where it does not.

Good fit

You need real run state

Your application should distinguish accepted, executing, waiting for approval, verifying, completed, failed, and needs attention.

Good fit

You need evidence attached

A durable result should expose its receipt, verification class, source coverage, and unresolved uncertainty.

Good fit

You need customer-controlled context

Context must be inspectable, correctable, quarantinable, forgettable, and separate from journey analytics.

Good fit

You need server-side automation

The job should continue through an API without requiring a particular desktop application to remain open.

The honest gate

Choose another road when the need is different.

Not the first choice

You only need conversational text

A direct model API is usually simpler when run state, tools, evidence, and durable context add no value.

Not the first choice

Your work happens entirely in one IDE

A coding agent already embedded in that environment may offer a more direct interaction model.

Not the first choice

You require an unlisted capability

If the operation is not in the live contract, treat it as unavailable rather than inferring it from roadmap language.

Not the first choice

You want effects without approvals

This service keeps authentication, authority, and effect approval distinct. That boundary is intentional.

Verify the claim yourself

The contract is the map.

Use the searchable API guide for discovery, then use the OpenAPI document and live endpoint response for implementation. Marketing copy does not expand the contract.

GET /openapi.json

Check:
• operation exists
• request schema matches
• response state is explicit
• required approval is visible
• uncertainty remains bounded