AI Contract Intake Agent: Request Packet and Cost Worksheet

Contract intake is a routing problem before it is a drafting problem. The first useful outcome is not generated language. It is an authoritative packet that tells legal, security, privacy, finance and the business owner what is being requested, which evidence supports it and who must decide next.

That boundary makes a practical first agent possible. The agent can normalize evidence, detect missing fields, choose a route already defined in a playbook and prepare an approved template after the required decisions exist. It cannot supply legal judgment or business authority that the packet does not contain.

This worksheet is operational guidance, not legal advice. Contract requirements, professional duties and approval authority vary by organization and jurisdiction. The accountable legal and business owners must define the playbook before an agent applies it.

Bound one intake lane

Choose one repeatable contract type, one legal entity, one system of record and one playbook version. A mutual nondisclosure agreement on approved company paper is a more useful pilot than every agreement entering the company.

Write the pilot boundary as a sentence:

The agent may:

• normalize request fields from an approved form or mailbox;
• bind each material field to a source and timestamp;
• classify paper as an approved template or counterparty paper;
• detect missing evidence, specialist flags and deviations;
• select a route already encoded in the current playbook;
• prepare an approved template after legal and business approval;
• write a bounded record to the contract system;
• read that record back and compare it with the authorized packet.

The agent may not:

• decide what the law requires;
• determine privilege or confidentiality by itself;
• waive a term, accept risk or approve a policy exception;
• negotiate with a counterparty;
• choose the legal entity or authorized signer;
• sign, execute or release an agreement;
• retry an uncertain write without authoritative read-back.

Those exclusions are not ceremonial. They determine the tools, permissions, user interface, tests and incident path.

NIST AI RMF 1.0 is a voluntary risk-management framework, not a certification. Its current core calls for organizations to define the specific tasks an AI supports, document its knowledge limits, differentiate human and AI roles, define human oversight and test systems under deployment-like conditions. NIST also says the 1.0 framework is being revised. Use its control questions as a structure, then map the workflow to current legal, regulatory and customer requirements.

Build the request packet before inference

The packet is the unit of work. A chat transcript or generated summary is not enough because a reviewer needs stable fields, source identity and the policy version used to select the route.

At minimum, retain:

• request ID, requester and submission time;
• business owner and accountable cost center;
• company legal entity and counterparty legal name;
• contract type and business purpose;
• paper source: approved template or counterparty paper;
• requested effective or signature date;
• data classification and document location;
• whether customer, employee, health, payment or other specialist data is involved;
• service, product and territory in scope;
• material commercial fields required by the intake playbook;
• security, privacy, tax, insurance, procurement and finance flags;
• requested deviations from the approved template or playbook;
• playbook, template and routing-policy versions;
• source digest and normalized intake digest;
• required reviewer IDs and later approval receipts;
• draft or system-write receipt;
• authoritative read-back and reconciliation state.

One versioned object is enough to start:

{
  "request_id": "CTR-1042",
  "business_owner": "revenue-operations",
  "legal_entity": "Example US Inc.",
  "counterparty": "Example Supplier LLC",
  "contract_type": "mutual-nda",
  "paper_source": "approved-template",
  "business_purpose": "Evaluate a supplier",
  "data_classification": "confidential",
  "requested_signature_date": "2026-11-15",
  "playbook_version": "2026-10-18",
  "source_digest": "sha256:source",
  "intake_digest": "sha256:intake",
  "specialist_flags": [],
  "approvals": {
    "business": null,
    "legal": null
  },
  "draft_receipt": null,
  "authoritative_record": null
}

The values are illustrative. The useful design choice is that the source packet, approvals, write receipt and read-back are different fields. A later reviewer can reconstruct which evidence and playbook produced the route.

Admit documents to the tool separately

An employee's permission to open a contract does not automatically permit copying it into any model or external service. Tool admission is a separate control.

ABA Formal Opinion 512, published July 29, 2024, addresses lawyers using generative AI under the ABA Model Rules. It says lawyers must consider competence, confidentiality, communication, supervision, candor and reasonable fees. Before entering information relating to a client representation into a generative AI tool, lawyers must evaluate disclosure and unauthorized-access risks, including the tool's terms, privacy policy and related contractual policies.

The opinion is not a universal contract-automation law. It applies to lawyers' professional duties under its stated rules and does not replace jurisdiction-specific advice. Its operational lesson is still sharp: tool admission cannot be inferred from possession of a document.

Record an admission decision for each document class and tool configuration:

• approved provider and exact product or tenant;
• training and retention settings;
• subprocessors and data location where relevant;
• access controls and logging;
• allowed data classes and matter types;
• whether client consent or another authorization is required;
• redaction or field-minimization rules;
• policy owner, effective date and review date.

If the packet contains client information and the exact tool configuration has not been approved, route to CONFIDENTIALITY_REVIEW. Do not send the document with a warning attached. The warning would arrive after the disclosure.

Keep routing separate from legal judgment

The route classifier should answer a narrow question: which customer-approved owner receives this packet next? It should not answer whether a clause is lawful, material or acceptable.

ABA Opinion 512 says generative AI may assist with contract review and drafting, but lawyers may not rely on it alone for legal advice, negotiation or other functions requiring professional judgment. It also says the amount of independent verification depends on the tool and task, while the lawyer remains responsible for the client work.

Translate that into system behavior:

• a privacy flag selects the privacy route but does not decide the privacy issue;
• counterparty paper selects legal review but does not approve the paper;
• a requested deviation selects an exception hold but does not price or accept the deviation;
• an approved template with complete evidence may become ready to draft only after the required legal and business receipts exist;
• a generated draft remains a draft until an accountable reviewer accepts it through the customer's process.

The route should be deterministic for the fields that confer authority. A model can extract candidate values, but critical fields such as legal entity, paper source, playbook version and approval identity should be selected or confirmed through controlled values. Store the raw source, extracted value, confirmer and timestamp.

Use the agent workflow operating contract to bind allowed actions, stops and owners. The same contract should state what happens when a source changes after approval. A changed counterparty name, legal entity, template digest or material field should invalidate the old packet or force a named re-review. Quietly carrying approvals forward creates an authority bug, not an efficiency gain.

Use observable terminals

Every run should end in a state an operator can act on:

RECONCILED is intentionally modest. It says the intake record matches the approved packet. It does not say the agreement is signed, enforceable, risk-free, profitable or correctly interpreted.

Keep drafting, negotiation, signature and post-signature obligations as later workflows with their own authority and evidence. Do not let one green intake state become a universal contract status.

Test the reference model

The retained dependency-free reference model passes twenty-four of twenty-four synthetic checks. Nineteen table-driven cases exercise missing fields, unsupported values, confidentiality admission, conflict status, specialist routes, policy exceptions, missing approvals, draft readiness, absent read-back, divergence and reconciliation. Five additional checks cover specialist deduplication, exact mismatch reporting, stable record digests, joined cost arithmetic and a zero denominator.

The core order is small:

if (requiredPacketFieldsMissing) return "COLLECT_EVIDENCE";
if (clientInformation && toolAdmission !== "approved") return "CONFIDENTIALITY_REVIEW";
if (conflictCheck !== "clear") return "LEGAL_REVIEW";
if (specialistFlags.length) return "SPECIALIST_REVIEW";
if (policyException || requestedDeviation) return "HOLD_EXCEPTION";
if (!businessApproval) return "BUSINESS_APPROVAL";
if (!legalReview) return "LEGAL_REVIEW";
if (!draftReceipt) return "READY_TO_DRAFT";
if (!authoritativeReadback) return "UNCERTAIN";
if (readbackDiffersFromPacket) return "DIVERGENT";
return "RECONCILED";

These tests prove that one implementation follows the declared route contract. They do not prove extraction accuracy, legal correctness, confidentiality, provider security, contract validity or customer results.

Test with representative failures before enabling a write:

1. an incomplete approved-template request;
2. counterparty paper;
3. confidential client information with an unapproved tool;
4. a privacy or security specialist flag;
5. a requested playbook deviation;
6. a changed legal entity after approval;
7. a duplicate delivery of the same request;
8. a write timeout where the record already exists;
9. a read-back with a different source digest;
10. an authoritative record that matches every required receipt.

The tool receipt and outcome verification guide explains why an accepted tool call is not the business outcome. Apply that rule here: after any record write, read the contract system by stable request ID and compare the authoritative fields before retry or close.

Fill the cost worksheet

Measure cost per reconciled intake. A submitted form, extracted clause or generated draft is an activity count, not an accepted outcome.

Use monthly values from your own process:

Calculate:

human cost = (legal hours
            + privacy and security hours
            + business approval hours
            + rework hours) * loaded hourly cost

joined monthly cost = platform and runtime
                    + integration operations
                    + amortized setup
                    + maintenance
                    + human cost

cost per reconciled intake = joined monthly cost / reconciled requests

Synthetic arithmetic check

The retained fixture uses deliberately synthetic values to prove the formula:

• platform and runtime: $300;
• integration operations: $500;
• setup: $12,000 amortized across twelve months, or $1,000 monthly;
• maintenance: $0 in the fixture;
• thirty legal hours;
• ten privacy and security hours;
• eight business-approval hours;
• six rework hours;
• $120 synthetic loaded hourly cost;
• ninety reconciled requests.

The fifty-four human hours produce $6,480 of synthetic human cost. Joined monthly cost is $8,280, or $92.00 across ninety reconciled requests. These numbers are not market prices, savings, fee advice, a forecast, a benchmark or a client result. Replace every value, include actual maintenance and compare the joined result with the current process.

Track the terminal distribution beside cost. A lower unit number can hide a growing confidentiality queue, specialist backlog or unresolved divergence.

Release one canary

Use a staged rollout:

1. Select one contract type, legal entity, approved template and playbook owner.
2. Name the business owner, legal reviewer, specialist routes, recovery owner and system-of-record owner.
3. Inventory document classes and approve exact tool configurations before sending contract content.
4. Define required packet fields, controlled values, source digests and freshness rules.
5. Run in shadow mode and compare packets with the current intake process.
6. Test missing evidence, counterparty paper, confidential information, specialist flags and deviations.
7. Enable route suggestions while reviewers retain every decision.
8. Permit approved-template drafting only after exact legal and business receipts.
9. Write by stable request ID with idempotency protection.
10. Read the authoritative record and route absence to UNCERTAIN, not blind retry.
11. Route field mismatches to DIVERGENT and test recovery.
12. Join operating cost, retained human time and terminal distribution.
13. Expand only after the first lane is inspectable, reversible and cheaper or better on the customer's chosen measure.

The release review should include a legal professional, the business owner, privacy or security when their data is involved, and the engineer who owns the integration. NIST's current core calls for documented test sets, production monitoring and safe failure beyond knowledge limits. ABA Opinion 512 also places clear policy and training duties on lawyers with managerial and supervisory responsibilities when generative AI is used.

Do not use a successful low-risk template lane to infer readiness for complex counterparty paper, regulated data, negotiation or signature. Each new task changes the authority, evidence and failure surface.

AI contract intake agent FAQ