The Exoskeleton in Motion
A judgment-heavy product counsel scenario, a self-improving feedback loop — and why this is just one practice area of many.
In the series so far, I outlined the problem of attention and judgment misdeployed, and legal teams unprepared for an AI-enabled tsunami of intake. In the second piece, I described an “exoskeleton” framework — a four-layer architecture designed to protect attention and deploy judgment where it actually counts.
This article shows the architecture at work.
None of what follows is speculative. The skills, workflows, and feedback loops described here are possible with technology that exists today. It is a description of a design pattern that can be built now — and in some places already is.
Now for the scenario: Steph is product counsel at a 200-person Series B SaaS company building an AI-powered HR platform. She is one of three lawyers on the in-house legal team. The feature under review is an AI recommendation engine that surfaces role and development suggestions to employees based on behavioural and performance data. Product wants to ship in six weeks.
This is a complex, judgment heavy workstream that crosses product counsel, privacy, and AI governance simultaneously. It involves precisely the depth and breadth of context that makes a one-shot prompt useless. It is exactly the kind of matter that gets fifteen minutes when it deserves two hours — and the kind that the exoskeleton is designed to improve judgment quality.
What follows is what happens when Steph’s legal function is built around the exoskeleton architecture. The tools are described by what they do, and do not hew to a specific platform. A close reader will recognize the design pattern. That is the point.
Before the Lawyer Opens a Single Document
The feature review request arrives. The product manager has submitted a brief — feature description, target ship date, a note that the underlying model is from a third-party vendor. Under the current model, this lands in Steph’s queue alongside everything else, waits for her to find it, and then requires her to spend the first hour of her engagement just understanding the landscape.
Under the exoskeleton, the setup work has already been done before she touches it.
A context assembly skill specifically for feature reviews reads the brief and does the pre-work automatically. It pulls the prior feature reviews for this product team — what positions were taken, what was flagged, what was approved and on what conditions. It surfaces the relevant regulatory landscape: what the applicable privacy frameworks say about automated decision-making in employment contexts, what the relevant data protection authorities have said recently about AI-generated recommendations, where the active enforcement attention is. Where the gaps are that might be worth a closer look with outside counsel. It loads the company’s internal policy context — the AI use policy, the data governance framework, whether the underlying vendor has been reviewed before.
The attention management layer has also been at work. A scheduled agent or “cron job” runs every morning and suggests size-appropriate slots for workstreams based on deadlines, Steph’s preferences (she frequently has meetings with Europe in the mornings so prefers to do deep work in the afternoons) and workstream size. This is not a fifteen-minute job. It requires depth, cross-domain thinking, and enough uninterrupted time to actually hold the full risk picture simultaneously. A “do not disturb” work block is scheduled Thursday afternoon. Steph can look at it when she’s most ready to give it the attention it needs, instead of being pressured to look at it in the 15 minutes she has between meetings.
The output of the context assembly skill is not a conclusion. It is a structured picture of the domains that need attention and the context relevant to each. By the time Steph opens the brief, the reading time is thirty minutes rather than three hours. The judgment work has not been done for her. The conditions for doing it well have been created.
The Feature Review Itself
Steph engages. Based on the context assembly brief, she kicks off three parallel workstreams — each handled by a dedicated skill, each oriented toward a different domain.
Product risk
A skill assesses the feature against the company’s calibrated risk framework — not generic legal risk, but risk as this company has defined it based on prior reviews, regulatory posture, and litigation history. The calibration matters: a risk that would be high at a company under a consent decree might be medium at one that is not. The assessment produces a structured analysis for each distinct risk — what could go wrong, how likely, how bad, what existing mitigations address it, what gap remains. It aims for two to five risks, not fifteen. It closes with a named recommendation: a specific option, a reason, an acknowledgment of what is being traded off.
What it does not do is make the call. The recommendation is a brief to Steph, not a decision. Steph reads it, applies the judgment that comes from knowing this company, this product team, and this regulatory moment, and decides.
Privacy
In parallel, a privacy skill runs an impact assessment — data flows, legal basis for processing, retention periods, third-party exposure, cross-border transfer implications. It identifies where the behavioural data collection intersects with the applicable frameworks and flags what needs resolution before the feature ships. It notes where its analysis overlaps with the product risk assessment so Steph is not reading the same ground twice.
AI governance
A third skill generates an AI impact assessment for the recommendation engine specifically. What the model does. What data it trains on. What the failure modes are and how consequential they would be. What human oversight exists in the feature design. Whether the model’s outputs are explainable to the people affected by them. This is not a product risk document — it is a governance record, formatted for the audit trail the company needs to maintain as AI regulation hardens.
The three outputs arrive together, cross-referenced. Steph reads a single brief that holds the full picture rather than three separate documents that each assume she has read the other two.
The fourth workstream she did not have to ask for
The AI governance assessment flags that the underlying model vendor has not previously been reviewed. A fourth skill queues a vendor AI review automatically — checking the vendor’s AI use policies, data handling practices, model governance documentation, and contractual representations. It does not wait for Steph to notice the gap and remember to close it. The system closes it.
What Steph does in this layer is not assembly. It is not coordination. It is the thing that only she can do: reading the full picture, applying judgment to the open questions, making the calls that require her expertise and carry her accountability.
The Feedback Loop
Steph makes her calls. She approves the feature with three conditions: a change to how the recommendation outputs are surfaced to employees, a requirement for explainability documentation before ship, and a cap on the data retention period. These are not standard playbook positions — they are judgments made in response to the specific design of this feature.
The system captures the decision in the log for this feature, organized by product team and indexed against the feature description. Six weeks later, when a question arises — what did we decide on automated decision-making disclosure? — the answer is one query away. Not a memory test or a trip down an email chain rabbit hole.
The capture step is configurable. Steph has it set to automatic. She trusts her decisions and does not want an extra step between making a call and having it logged. Her colleague on the same team runs a brief sanity check before anything is recorded — the system surfaces a one-paragraph summary of what it is about to log and waits for his confirmation before writing. Same outcome, different workflow. The exoskeleton bends to each lawyer, not the other way around.
The log also notes where this review deviated from the company’s standard playbook — a new position on explainability requirements, a new threshold for data retention in AI-driven features. If deviations hit a frequency trigger or risk threshold set by the GC, an agent automatically surfaces these for approval: is this deviation a one-off, or does the playbook need to change? If the same judgment gets made three times in three separate reviews, it probably should. The system makes that pattern visible. The GC decides what to do with it.
Institutional knowledge does not evaporate when Steph moves on to the next matter. It compounds. Every review makes the next one faster, more consistent, and better calibrated to how this company actually thinks about risk.
Three Smaller Scenarios
The feature review is the complex case. Here are three illustrations of the exoskeleton working at different layers, on different timescales.
THE MONDAY MORNING REGULATORY BRIEFING
Every Monday at 7am, a cron job scans the relevant regulatory feeds — employment AI, privacy, consumer protection — for developments that intersect with the company’s current product pipeline and risk posture. It cross-references against active features in development and flags where a recent regulatory development touches something in flight. Steph opens her laptop on Monday morning to a briefing: here is what moved last week, here is what it means for the two features currently in review, here is what needs attention and what does not.
Nothing competed for her attention over the weekend. The horizon was being watched while she was not. She did not have to remember to check. The intelligence arrived.
THE FEATURE THAT FLAGS ITSELF
A product manager adds a new feature to the launch tracker on a Tuesday afternoon. She is not sure whether it needs a review. She runs it against a skill that the legal team created and externalized for product team use to answer the frequently asked question: does this feature meet review thresholds? This feature — a change to how performance data feeds into the recommendation engine — crosses the threshold. A triage message goes to the product manager automatically: this one needs a review before it ships, here is how to submit the brief, here is roughly what to expect.
Steph never had to monitor the pipeline herself. The feature did not slip through because nobody thought to flag it. The system caught it on Tuesday afternoon, before it was a problem.
THE INCOMPLETE SUBMISSION THAT DEFLECTS ITSELF
A product manager sends an email intending to submit a feature request, but did not attach the right product spec document in the message. A triage skill detects the incomplete submission and drafts an email asking for the right document. Steph has the skill configured to auto-send “incomplete submission” replies — her colleague prefers to batch review these manually in gaps between meetings. The deflection layer does its job in accordance with individual trust preferences.
This Is One Practice Area
Everything described above is product counsel. One vertical of what a three-lawyer in-house team handles.
The same architecture applies across the full practice map. Commercial contracts: vendor reviews, MSA negotiations, escalation routing, stakeholder summaries. Employment law: hiring reviews, termination risk, handbook updates, classification questions, investigations. Corporate: board consents, closing checklists, entity compliance, diligence extraction. AI governance: use case triage, vendor AI review, policy monitoring, impact assessment generation. Regulatory: horizon scanning, gap analysis, policy diff against current positions.
Each practice area has its own skills, its own calibrated playbook, its own escalation thresholds. But the architecture underneath is identical: deflect what does not need a lawyer, assemble context for what does, protect attention until the right moment, capture what is decided so the next matter is easier. The exoskeleton does not look different by practice area. The skills do.
The exoskeleton is a model for how in-house legal functions should be built — one that puts attention and judgment where they belong, and automates everything that does not require them.
There is one question this series has not yet answered: who governs all of this? Who owns the playbook. How you keep the system current as the law changes and the company evolves. What happens when a skill is working on stale guidance. What it means for the function that is supposed to provide AI governance to also need AI governance itself.
That is the next piece.
Natalie Kim
Natalie is the founder of Inflection Advisory and works with organizations on AI acceleration and governance. As VP Legal at Omnidian she led a full-arc enterprise AI adoption.
The Judgment Layer publishes on AI governance, board accountability, legal intelligence, and the judgment no algorithm is taking from you.