Build: Contract review

In one line. A Processing collection plus one extraction agent that flags risky clauses, scores a risk band, and suggests fallback wording — a copilot for a lawyer, never the final word. You’ll build. A Contracts collection with a clause table in its fields, a clause-detection skill, a fallback-language tool, the “Contract Reviewer” agent with structured output, an advisory guard rail, a Legal-Reviewer persona, and the human review loop in the document detail. You’ll use. Collections & schema, Skills & skill packs, Tools & functions, Your first agent, Guard rails, Document detail.

Someone in legal has to read every incoming NDA, MSA, or vendor agreement, hunt for the dangerous clauses — auto-renewal, uncapped liability, one-sided indemnity, missing termination rights — judge the risk, and suggest safer wording. That first-pass triage is exactly the kind of bounded reading an agent does well. Budget 60–75 minutes for a first build. Prerequisites: one language model registered in the project (LLMs & services), and basic comfort with the agent editor and a collection’s Taxonomy tab.

A word of honesty up front — this is a copilot, not a compliance gate. The agent flags risky clauses and suggests fallback language; a qualified human decides. In particular, the guard rail you’ll add steers the agent; it does not check the answer afterwards and block it. It keeps the agent in scope and in tone, but nothing reads the finished answer back and stops it. Treat every output as a first draft for a qualified human. See Guard rails for exactly what a guard rail does and doesn’t enforce.

Seven pieces: a collection (the typed home), a skill (what to look for), a tool (what to suggest), an agent (that does the reading), a guard rail (that keeps it in lane), a persona (who reviews), and a review experience (where a human reads the findings). We build them in that order.

Steps

Stage 1 — The collection and its fields

A contract is something you decide about (sign / negotiate / reject), document by document — so it’s a Processing collection, not Knowledge.

1. Go to Studio > Data > Collections. Click + Collection.
2. Purpose: leave Processing selected. This is immutable after create — pick it deliberately.
3. Collection Name: Contracts. Description: Incoming agreements for clause review and risk triage.
4. Allowed Ingestion Types (optional): leave default (Upload) so you can drag in a sample NDA.
5. Click Save. Contracts appears in the collection list — select it. You should see its tab strip: General · Taxonomy · Lifecycle · Tags · Events · Ingestion · Agents.

The fields drive extraction — the agent fills in exactly the Labels (UI: Fields) you define, no more. We want header facts, a table of detected clauses, and an overall risk band.

6. With Contracts selected, open the Taxonomy tab.

7. Click Taxonomy at the bottom of the list to create the Learner (the extractor that owns these fields): Taxonomy Name Contract Review, Description Header facts, detected risky clauses, and an overall risk band, Type DocumentClassification (whole-document field extraction), Entity Contracts (pre-filled). Submit.

8. Select Contract Review, then + Label for each header field (use Add between them):

   Label name	Description	Shape — how to get it
   counterparty	The other party to the agreement	Plain text (default)
   contract_type	NDA, MSA, SOW, vendor agreement, etc.	Plain text
   effective_date	The date the contract takes effect	View Config ▸ Validation → date
   renewal_date	Next auto-renewal / expiry date, if any	View Config ▸ Validation → date
   risk_band	Overall risk: Low, Medium, or High	View Config ▸ Validation → allowed values Low, Medium, High

9. Now the important one — a table field for the clauses the agent flags. Click + Label: Label Name detected_clauses, Description One row per risky clause the agent flags. Open Show Advanced Settings ▸ Record Config and turn on Is Record (this makes it a table).

10. Add child Labels as its columns (each child = one column), then Add and exit:

    • clause_type — e.g. auto-renewal, uncapped liability, one-sided indemnity (text)
    • severity — Low / Medium / High (View Config ▸ Validation → allowed values)
    • excerpt — The exact wording detected (text)
    • suggested_fallback — Safer language to propose (text)

If you’d rather not click the columns in one by one, build the field list in a spreadsheet (one column per nesting level) and use the Import labels tab instead — see Collections & schema. When you’re done, the Labels tree under Contract Review shows the five header fields plus detected_clauses as a table with 4 child fields.

Stage 2 — The capabilities: a skill and a tool

A Skill is a reusable playbook: a name, a “use when…” description for discovery, and a Markdown body that says how to do the job. We want one that teaches any agent how to scan a contract and surface risky clauses.

11. Go to Studio > Agents > Agent Toolkit > Skills. On the Skills tab, click + Skill.

12. On the Form tab: Name detect-risky-clauses (lower-kebab — this is the handle agents refer to). Description: Scan a contract and flag risky clauses (NDA scope, indemnity, liability cap, auto-renewal, termination, governing law). Use when the document is a contract or agreement. The “use when…” half is what tells an agent to reach for this skill — don’t skip it. Tags: contract, legal, risk.

13. Switch to the Markdown tab and write the body — the instructions the agent reads when it invokes the skill. Something like:

    Read the supplied contract. Identify clauses in these risk categories and report each you find:
    - Auto-renewal — does it renew automatically? Capture the notice period and renewal date.
    - Liability — is liability uncapped, or capped at an unusually high multiple? Flag uncapped.
    - Indemnity — is indemnity one-sided (only one party indemnifies)? Flag asymmetry.
    - Termination — can we terminate for convenience? Flag if only the counterparty can.
    - Confidentiality / NDA scope — is the definition of "Confidential Information" overbroad or perpetual?
    - Governing law / jurisdiction — flag an unexpected or unfavourable jurisdiction.
    
    For each clause you flag, return: the clause_type, a severity (Low / Medium / High),
    the excerpt (the exact wording), and — if you have a suggested-fallback tool available —
    call it for safer language and put the result in suggested_fallback. Quote wording from the
    document; never invent clauses that aren't there. If a category isn't present, simply omit it.

14. Click Create. detect-risky-clauses appears in the Skills list with a V1 version chip and a Project scope badge (it’s yours to edit).

A Tool is a single callable the agent invokes mid-run. Here we want a lookup that, given a clause type, returns your firm’s preferred fallback wording — so suggestions come from your playbook, not the model’s imagination. Point it at whatever endpoint your team exposes (or a small internal service that returns canned redlines).

15. Go to Studio > Agents > Agent Toolkit > Tools. Click + Tool.

16. In the import grid, filter Filter by type → API Endpoint and import the closest GET-style card. The dialog flips to form view.

17. Tool Name: fallback-language-lookup. Tool Description (the model reads this to decide whether to call it — make it say what and when): Look up your organisation’s preferred fallback wording for a risky contract clause. Use this whenever you have flagged a clause and need to suggest safer alternative language.

18. In the code editor, point the API URL at your fallback-language endpoint, set the method, and declare the input schema, e.g.:

    {
      "clause_type": { "type": "string", "description": "e.g. auto-renewal, uncapped-liability, one-sided-indemnity" }
    }

19. If the endpoint needs a key: under Default parameter values, add a row, pick the key parameter, set its type to sensitive, and paste the key — it will be masked. Never put credentials in the description or URL.

20. Save. The tool appears in the list with a read-only Snippet on the right.

No external API yet? Two honest fallbacks: (a) skip this tool for now and let the skill body ask the agent to propose fallback wording from the contract context — less consistent, but real today; or (b) author the fallback wording as a Library snippet or a Datasheet the agent reads — see Library & bots and Drive & datasheet. The custom-API tool is the cleanest route once your firm exposes a clause-language service.

Stage 3 — The agent

Now assemble the worker. Full editor tour: Your first agent. The editor opens as a full-window dialog with a builder pane on the left and a live Playground on the right.

21. Go to Studio > Agents > Agent Toolkit > Agents → + Agent ▸ Agent.

22. Persona tab. Name: Contract Reviewer. Description: Flags risky clauses, scores a risk band, and suggests fallback language for human review. Instructions (use the co-pilot to seed, then edit to roughly):

    You are a cautious contract-review paralegal. For each contract, use your clause-detection
    skill to find risky clauses, and for each flagged clause suggest safer fallback language.
    Then assign an overall risk_band of Low, Medium, or High based on the worst clauses you
    found. You flag and suggest — you never give legal advice or decide whether to sign. Only
    report clauses actually present in the document; quote the wording. A qualified human makes
    the final call.

23. Model tab. Pick your project’s language model. Set Agent Mode = Thinking while you build (so you can watch its reasoning); switch to Fast for production later. Keep Temperature low under Advanced sampling — this is judgement-sensitive reading, not creative writing.

24. Knowledge tab. Under Views, leave it scoped to this collection’s own documents (the agent reads the contract in front of it). You don’t need a separate Knowledge collection for this build.

25. Capabilities tab. Skills → + Pin skill → detect-risky-clauses (it shows as a Pinned card). Tools → + Add tool → fallback-language-lookup (a card under Tools). Optionally tick Restrict this agent to pinned skills only for tight, predictable behaviour.

26. Output tab. Turn on Structured output. Choose the Taxonomy/Learner Contract Review, set Process unit = Page, and add Labels matching your fields: counterparty, contract_type, effective_date, renewal_date, detected_clauses (the table) and risk_band — give each a short Description. Turn on Confidence Score and References so a reviewer can see where each value came from, and how sure the agent is.

27. Governance tab. Guard rail comes in the next stage. If a flagged contract should later trigger an external action (e.g. post to a CLM system via a tool), add a per-tool Approval here so a human signs off first — this gives you a real Approve & Execute / Review / Reject card.

28. Click Save Agent.

29. Test it now: in the Playground (right pane), set Input Type = Document, pick a sample contract, and Send. Watch the transcript: a tool call to fallback-language-lookup, the detected_clauses table filling in with severities and excerpts, a risk_band, and References back to the page. Wrong field? Sharpen its Description on the Output tab and re-run.

Stage 4 — The guard rail, honestly

A guard rail is a named, reusable policy — a single instruction — that the platform adds to the agent’s instructions when it runs. It steers the agent; it does not read the answer back and block it. So we use it for what it’s genuinely good at: keeping the agent in scope (contract review only) and in tone (professional, no legal advice).

30. Go to Studio > Agents > Agent Toolkit > Guard Rails. Click + Guard Rail.

31. Name: Scope & Tone: Contract Review. Description: Keep the agent to contract-review scope and a professional, non-advisory tone. (Max 200 characters.)

32. Instruction — phrase it as a direct order; it reaches the agent word for word:

    You assist only with reviewing the contract in front of you: flagging clauses, suggesting
    fallback wording, and scoring risk. Maintain a neutral, professional tone. Do not give
    legal advice, do not state whether the contract should be signed, and do not answer
    off-topic questions — if asked, politely say you only help with contract clause review.
    Always note that a qualified human must make the final decision.

33. Save. Confirm it shows in the list with your instruction in the detail panel.

34. Go back to Studio > Agents > Agent Toolkit > Agents, Edit Contract Reviewer, open the Governance tab, click + Add under Guard rails, select Scope & Tone: Contract Review (it appears as a shield chip), and Save Agent.

Watch out — it steers, it doesn’t stop. This guard rail strongly steers the agent, but the platform won’t independently block an off-tone or off-scope answer. For anything that must be enforced, layer it: a clear guard rail plus the human approval in the review loop below plus tight knowledge scope. In the Playground, test it: ask "should we sign this?" — the agent should decline to advise and steer back to clause review. If it doesn’t, sharpen the instruction’s wording.

Stage 5 — Who reviews: the Legal-Reviewer persona

The loop you’re about to build hands uncertain contracts to “a lawyer”. Say who that is, in the platform’s own terms. A persona is this project’s workflow role — the vocabulary your solution uses, separate from platform administration.

35. Go to Studio > Governance > Access > Users & Access and open the Personas view (Access & roles).
36. + Add persona → name it Legal-Reviewer. Choose the Contracts collection and the review stage it works in, and grant the review actions a lawyer needs — read the contract, correct a field, advance the document.
37. Switch to the People view and add your lawyers to that persona. If someone should only ever read, give them the Viewer workspace role instead.
38. Back on the collection’s Lifecycle tab, open the review stage and set Can be viewed by to Legal-Reviewer. Now contracts waiting on a human sit in front of exactly the people who should see them, and nobody else.

Stage 6 — Wire it up and test the whole loop

An agent only processes documents once it’s a collection’s Worker (Intake Agent).

39. Go to Studio > Data > Collections, select Contracts, open the Agents tab.
40. Assign Contract Reviewer as the collection’s intake/processing agent. The tab shows the assignment with a link back to the agent editor. From now on every contract that lands in Contracts — uploaded or pulled in by a connector — is run by the agent automatically, filling the fields and entering the review lifecycle.
41. Upload a real NDA or MSA. From the Contracts collection (or the consumer document list), add a sample contract. It shows in the list with a Processing… chip.
42. Watch it process. Open the document — the Document detail fills in live as the agent finishes: header fields, the detected_clauses table, and a risk_band.
43. Read the findings as a lawyer would. In the Summary pane: read the flagged / low-confidence fields first; click a clause’s excerpt — the viewer scrolls to and highlights the source segment (the agent shows its work — verify it read the real wording); check the risk_band and each clause’s severity and suggested_fallback.
44. Correct and advance. Fix any wrong value in place — it saves back to the Label and becomes a training signal (AI Builder). Then use the workflow action pane to advance the document through its review stages (e.g. approve / needs-info / reject), each persona-gated and written to the audit trail you can read at Studio > Governance > Oversight > Audit & Usage.

What “good” looks like: on a contract with an auto-renewal and an uncapped-liability clause, the agent flags both with High/Medium severities, quotes the wording, proposes fallback language for each, and scores risk_band = High — and a reviewer can verify every flag against the highlighted source in one click.

Make it production-worthy

• A clause library. Instead of (or alongside) the API tool, hold your firm’s preferred fallback wording in a Datasheet (Drive & datasheet) the agent queries with the built-in SQL search toolkit, or as a Library snippet in a pipeline node (Library & bots). Structure your redlines once; reuse everywhere.
• A stricter guard rail — and real enforcement. Add a second guard rail (e.g. No External Disclosure) — but remember a guard rail steers rather than stops. For a hard stop, pair it with a human approval on any tool that writes anywhere, set on the agent’s Governance tab (Your first agent).
• An approval lifecycle. Customise the collection’s Lifecycle stages (Taxonomy, lifecycle, tags & events) so a High-risk contract is routed to a senior approver before sign-off — the “two humans confirm” rule, made real for risk. Give that approver its own persona and gate the stage to it.
• Export a redline summary. Use the document Export action (Document detail) to push the detected-clause table and fallback suggestions out to your counsel — or fire an Event/Webhook (Taxonomy, lifecycle, tags & events) on stage change.
• Share it. Publish the agent from its ⋮ ▸ Publish menu on Studio > Agents > Agent Toolkit > Agents; it lands in Hubs ▸ Agents, and its pinned skill and guard rail travel inside the package. The Hubs chip sits on the right of the top bar while you are in Studio (Hubs & distribution). Other projects then install the whole contract-review capability — structure travels, data doesn’t: the language model and anything pointing at data are wired to the installing project’s own objects.

Where to go next

• Build: Compliance evidence mapping — the next review-copilot pattern: mapping evidence to controls.
• Guard rails — exactly what a guard rail does and doesn’t enforce; re-read this if the “steers, doesn’t stop” point still feels surprising.
• Taxonomy, lifecycle, tags & events — design the approval stages a High-risk contract should route through.