The API should narrow the agent's job
Most eSignature API pages are written for developers building general document workflows. Agent workflows need a narrower promise. The agent should select an approved packet, fill known variables, run a dry run, and create a signing link only after the operator accepts the send.
That boundary matters because contracts are not ordinary notifications. If the API lets the agent generate legal language, pick risky terms, or treat a signature as a background task, the workflow becomes hard to trust. A safer eSignature API makes the irreversible step visible.
- Approved templates live outside the model prompt.
- Dry runs show recipient, template, fields, metadata, and webhook target.
- The signer reviews and consents in a browser, not inside an agent transcript.
- The completed record returns status, audit events, PDF bytes, and hashes.
The best response is structured state
A human dashboard can get away with visual cues. An agent workflow cannot. The API should return stable agreement ids, signing URLs, status values, timestamps, and webhook events that downstream code can reason about.
This is also how you avoid vague agent summaries like "it looks sent." The agent should be able to say which agreement was created, who received it, whether a reminder went out, and whether a signed PDF is available.
Use the API for ceremony, not legal judgment
The useful automation is the ceremony around the agreement: preparing the packet, sending the email, tracking status, reminding the recipient, and storing the executed record. The legal judgment stays with the people who approved the template and the signer who signs.
AgentContract is intentionally shaped around that operating model. It gives agents an API and CLI path for approved packets, while the human review and signature remain explicit.