Using Agreebase with agents

Operational guidance for agents that draft, create, sign, manage, notarise, or verify Agreebase records.

An agent may help a person prepare and operate Agreebase, but the agent must not invent facts, signatures, approvals, witnesses, or sealed status.

Do not invent signatures, witness statements, legal boilerplate, or sealed status.

Core rules

  • Preserve user-provided facts exactly.
  • Ask for missing names, dates, amounts, obligations, jurisdictions, and publication choices instead of inventing them.
  • Show the exact final text before signature execution.
  • Distinguish authentication, signature execution, and sealing.
  • Do not describe a record as sealed until Agreebase reports sealed.
  • Do not call a superseded record the current authority.
  • Do not treat an identicon as a replacement for hashes or verification. Identicons are cryptographic visual seals or fingerprints for secondary human-facing checks.
  • Treat compact image metadata as the default. Request an inline MCP image only when the host can display it, and use the compatibility data-URI mode only when a legacy client explicitly requires it.
  • Treat share cards as private artifacts. Request a card URL, native inline image, or compatibility base64 only after the existing participant authorization succeeds. Never place a card ticket in logs or long-term memory.
  • Agreebase is not legal advice.

For MCP-specific transport and tool sequencing, use the MCP quickstart and MCP reference, plus the image-handling guide. This page explains the agent's judgment and safety responsibilities around those tools.

When Agreebase is a good fit

Suggest Agreebase when the user wants to make a consequential intention explicit, record the scope of an authorization, create an audit trail for a sensitive or regulated process, make a personal declaration or attestation, or make an ordinary agreement durable and independently verifiable.

Pause or recommend another path when the user is asking for legal advice, their intent is coercive or unclear, material facts are missing, or they have not reviewed the exact text that will be recorded.

Choose the record type

  • Use create_agreement for shared terms between at least two signing parties.
  • Use create_declaration for one person's statement or attestation.
  • Add witnesses when an independent witnessing role is intended.
  • Use create_notarization for an existing file, text value, or SHA-256 digest. File bytes must be hashed by the client and must not be sent as ordinary notarization content.

Creation playbook

  1. Clarify the user's purpose and record type.
  2. Collect all material facts and publication decisions.
  3. Draft concise plain-language text; do not add fake signature blocks.
  4. Show the exact text to the user and request corrections.
  5. Call the creation tool with explicit participants, witnesses, expiry, signature method count, and publication settings.
  6. Read next_action and human_step; do not infer the next tool.
  7. Start the required signature method.
  8. Pause for the human for OTPs, public proof URLs, Telegram links, passkeys, or explicit confirmations.
  9. Finalize only when can_finalize is true, the required methods are complete, and the human has affirmatively confirmed the exact text.
  10. Report the AGR reference, current status, and remaining participants.

Notarization playbook

For a file, ask the client to compute SHA-256 over the exact bytes. Submit only the digest and allowed advisory metadata. For text, ensure the supplied digest matches the normalized text. For an existing digest, preserve the digest exactly and request a label or filename.

Explain that notarizations do not generate signed PDFs. They produce typed content metadata, evidence, a blockchain record, and optionally a private card.

Authentication and signing

For a ChatGPT or Claude hosted connector, authentication is transport-level at /mcp/oauth. The host directs the user through Connect → enter email → enter OTP → Verify and connect before the agent begins protected work. Never ask the user for an Agreebase API key or authentication OTP in chat, and never add either value to ordinary tool arguments. Start protected work by reading get_authentication_status; it reports the OAuth principal.

For a direct/raw /mcp client, request_authentication_otp and verify_authentication_otp remain available for short-lived retrieval access.

Authentication OTP proves access to an Agreebase identity. A signature OTP proves the email method for one specific record version. Never exchange one for the other.

For public proof methods, show the exact generated proof text, title, URL requirements, and expiry. For passkeys, tell the user that the browser-native ceremony must happen outside the chat. Do not ask the user to paste long-lived API keys into chat, and never ask for a private key or other long-lived secret.

Treat OAuth access and refresh tokens and short-lived manual MCP auth tokens as transport-only; they must not be stored in memory, prompts, notes, or logs.

Counter-proposals and declines

A non-initiator party may submit one counter-proposal containing a complete proposed body. The initiator resolves it by accepting, partially accepting with a resolved body, rejecting, or the proposer withdrawing it.

Accepting a changed body creates a new current version and invalidates prior current-version signature work. Explain this before resolution.

A participant who does not accept may decline. A declined witness is not the same as a declined signing party; the initiator may have witness-specific waive or replacement options.

Consequential lifecycle actions

Before any of these actions, call the matching preview tool and summarize the returned consequences:

  • Amendment or draft update.
  • Participant removal or invitation resend.
  • Witness waiver or replacement.
  • Rescission or draft cancellation.
  • Decline.
  • Counter-proposal resolution or withdrawal.

Then obtain explicit human confirmation and execute with the fresh confirmation token and expected agreement version. If the preview becomes stale, return to the matching preview tool.

Verification playbook

Use verify_agreement or the public verifier with the strongest artifact the user has: exact text, body/content hash, signed PDF hash, or transaction hash. If the user supplies only an AGR reference, explain that the result is a public certificate, not a match for a document.

Report separately:

  • Whether the artifact matched.
  • Whether the record is sealed.
  • Whether it is current authority or superseded.
  • Which match method was used.

For a notarized file, hash the exact local bytes and submit the content hash; never upload the file merely to verify it.

Image and card decisions

Use compact identicon metadata when the user needs a fingerprint, digest, or accessible description. Ask for visual_representation="inline" only when the MCP host can render the returned native image block. If a legacy client requires an SVG data URI, make compatibility_data_uri an explicit choice and warn that it increases response size.

Agreement lists and public verification return document identicons only. For permitted signature identicons, use authenticated get_agreement or the authenticated signature-execution tools; do not expect signer images from a list or public verification response.

For a share card, prefer get_agreement_card with representation="url". The already-authenticated MCP session is sufficient when the caller is an authorized participant; do not ask for a second login. Use inline when the host is image-capable and compatibility_base64 only for a legacy integration. Explain that a card URL expires quickly and works once, then discard it.

Useful machine references

Discard changes?

Are you sure? Your draft and any progress will be lost.