A repository does not negotiate anything

Workflow around the deal, or the deal itself

This is not a claim that CLM platforms are bad at what they do. It is a claim about which part of the problem each system is pointed at.

• Lifecycle management: Routes a document between people and records where it got to
• Lifecycle management: The negotiation itself happens in an attached file, outside the system's model
• Lifecycle management: Versions are documents — v3, v4, v4-final — so a change is a whole-file diff
• Lifecycle management: Counterparties usually sit outside, reached by email with a copy attached
• Lifecycle management: Approvals are workflow states; the reasoning behind them lives in comments
• Lifecycle management: Reporting describes contracts that already exist, not negotiations in flight
• Paqt: Runs the negotiation as the primary act, turn by turn, inside the record
• Paqt: Both sides work in one room, so there is no round-trip through anyone's inbox
• Paqt: Versions are clause-level positions with an author, a time and a rationale
• Paqt: An AI assistant takes the ordinary turns inside a mandate and escalates the rest
• Paqt: Approvals bind to the exact version and clause they were given for
• Paqt: The lifecycle data — obligations, renewals, deviation patterns — is a by-product of having negotiated here

The assistant does not route work to you

A workflow engine's job is to put the right task in front of the right person. That is useful, and it is still a queue. The assistant's job is to clear the queue and bring you only the decisions.

• A mandate replaces a routing rule — Instead of “send deviations over $50k to legal”, you state what positions are acceptable, tradeable and forbidden. The assistant negotiates inside that and stops at the edges.
• Turns are taken, not assigned — When the counterparty counters, the response is drafted and sent inside the mandate rather than appearing as a task somebody has to pick up.
• Escalations arrive as decisions — You get the clause, what changed, what your standard says and a recommended response — not a notification that a document is waiting.
• Autonomy is a setting you move — Shadow mode to evaluate against what your team would have done, supervised to run with escalation, autopilot for the paper you have stopped worrying about.

The lifecycle parts, without the lifecycle project

Nothing here is given up by moving the negotiation in-platform. It arrives as a consequence of the negotiation having happened in one place.

• Before signature: Request intake with the context attached
• Before signature: Templates and a clause library your team owns
• Before signature: Approval gates at the clause level, not just the document
• Before signature: Deviation tracking against your standard positions
• At signature: Native e-signature with identity capture
• At signature: Approvals bound to a version and an identity
• At signature: Timestamped, tamper-evident agreement history
• At signature: The executed agreement stored with its negotiation log
• After signature: Obligations extracted from the executed document
• After signature: Notice and renewal windows surfaced from the agreement itself
• After signature: Amendments resolved against the clauses they change
• After signature: The whole record exportable as a single package

Where lifecycle projects usually stall

• Adoption outside legal — A system the business has to visit gets avoided. Paqt's unit is a chat room with the counterparty in it, which is where the deal was happening anyway.
• Data that was never captured — Clause-level reporting needs clause-level data. If negotiation happened in attachments, that data was never created, and no amount of configuration recovers it.
• Counterparties who will not log in — The other side joins a room by link and works there. The negotiation does not fall back to email the moment an external party is involved.
• Reconciling two sources of truth — When the live document lives in a word processor and the record lives in a repository, they disagree. One record removes the reconciliation entirely.
• Proving who decided — Workflow states say a step completed. Attribution says which identity accepted which clause at which version — which is the question that actually gets asked.
• Headcount as the only throughput lever — Routing work faster still requires someone to do each turn. An assistant operating under a mandate changes the throughput ceiling rather than the queue order.

Where a CLM is the better answer

Some of what mature lifecycle platforms do is genuinely outside what we are built for, and a comparison page that pretends otherwise is not worth reading. Here is the real boundary.

A reasonable way to test this without a migration: run one agreement type here end to end — NDAs or vendor paper — and compare the record it produces against the one your current process leaves behind.

• Not our strength: A decade of executed paper that needs bulk migration and retrospective metadata extraction
• Not our strength: Deep configuration of long internal approval chains spanning many departments and entities
• Not our strength: Named connectors into your existing systems of record — we expose a Model Context Protocol surface and you connect your own
• Not our strength: Procurement or sourcing functions beyond the agreement, such as supplier scoring and spend management
• Our strength: Running the negotiation itself, clause by clause, with the counterparty in the room
• Our strength: An AI assistant that takes the ordinary turns under a mandate and escalates the rest
• Our strength: A record that explains itself: every position, approval and agent action attributed
• Our strength: Time to first value measured in a single agreement rather than an implementation

What evaluators ask here

• Is Paqt a CLM? It covers the lifecycle — intake, drafting, negotiation, approval, signature, obligations and renewals — but calling it a CLM gets the emphasis wrong. Lifecycle platforms are organised around managing a document as it moves between people. Paqt is organised around conducting the negotiation, and the lifecycle data is what the negotiation leaves behind.
• Do we have to replace what we already run? No, and we would not advise starting that way. Pick one agreement type where the negotiation is the bottleneck and run it here. Your existing repository keeps doing what it does for everything else while you judge the difference on real paper.
• How do our existing systems see this data? Through the Model Context Protocol surface. Your own agents and services connect over MCP with scoped credentials and read the agreements, clauses, obligations and run history directly. We do not claim named integrations, because we would rather give you a surface you control than a list you have to trust.
• Our approval chain is genuinely complicated. Does that work? Clause-level gates and named approvers cover most of it: any clause can be marked as requiring a specific reviewer before anything moves, and no autonomy level overrides that. What we do not have is deep multi-entity approval modelling, and if that is the centre of your requirement you should weigh it honestly against what the negotiation side buys you.