DEV Community: Blake Aber

Together AI Funding Round: What It Signals

Blake Aber — Mon, 12 Oct 2026 18:37:30 +0000

A large funding round in AI infrastructure says more about fund operations than it does about any single company's odds.

Blake Aber · Predicate Ventures

The round itself

Together AI closed a funding round that put a nine-figure sum behind a company selling access to open-source model training and inference. The investors were the names you would expect in a cycle where compute is the scarce input and distribution is the open question.

The headline number is easy to report and hard to interpret. A round tells you what a syndicate was willing to pay for a stake at a moment in time. It does not tell you whether the business compounds.

I read these announcements the way an operator reads them: not for the valuation, but for what the capital is meant to buy.

What the capital is actually for

Together AI sits in the layer between raw GPUs and the applications developers ship. It offers a platform for running and fine-tuning open models, competing on price, speed, and the breadth of models it supports.

That positioning determines where the money goes. Most of it buys compute capacity and the engineering to run that capacity efficiently. A smaller share buys the sales motion needed to move developers off incumbent clouds.

This matters because the economics of an infrastructure company are different from the economics of an application company. Infrastructure margins are made in utilization, not in features. A funding round here is a bet that the company can fill the hardware it buys faster than the hardware depreciates.

Where this changes a fund's operations

For a venture firm, a round like this is a data point, not a decision. The decision was already made or missed at the earlier stages where entry price and ownership were still negotiable.

Where AI changes how we run the fund is narrower than the market implies, and more durable.

Sourcing and triage

We use models to read the flow. When a round like Together AI's lands, it reshapes a category overnight: adjacent companies reprice, talent moves, and the set of fundable theses shifts. Tracking that by hand is slow.

Models help us compress the reading. They summarize filings, cluster companies by what they actually do rather than what they claim, and flag when a thesis we hold is being commoditized by a better-capitalized player. The judgment stays human. The reading gets faster.

Diligence on infrastructure claims

Infrastructure companies make specific, checkable claims—throughput, cost per token, model coverage. These are the easiest claims to verify and the easiest to overstate.

AI tooling helps us test them. We can run inference benchmarks ourselves, compare published pricing against observed behavior, and model unit economics under utilization scenarios the pitch deck chose not to show. This is grunt work that software does well and partners do slowly.

Where it does not help

It does not tell us whether open-source inference becomes a durable business or a race to zero margin. That question is about market structure, customer switching costs, and the behavior of three hyperscalers with their own silicon. No model answers it, because the answer has not been written yet.

It does not tell us whether this management team executes. We still take the meetings.

What the round signals about the category

The size of the round is a statement about belief in open models. Capital at this scale only flows to Together AI if a meaningful share of the market expects to build on open weights rather than on closed, API-only frontier models.

That belief is contested. The closed labs ship faster and spend more. The open ecosystem offers control, cost, and the ability to run models where data cannot leave.

A funding round does not settle the argument. It funds one side of it. For a fund holding positions near this layer, the useful read is directional: the money says open-weight infrastructure is a market large enough to support independent companies, at least for now.

Where AI changes portfolio value creation

Once a company is in the portfolio, the question shifts from selection to support. Here the operator view diverges from the vendor view.

Vendors sell AI as a line item that raises every portfolio company's performance. Operators know the effect is uneven and specific.

AI changes value creation in portfolio companies where three things are true at once: the company has proprietary data, a repetitive high-volume task, and a tolerance for probabilistic output. Support triage, document processing, code generation against a known codebase—these show measurable gains.

It does not change much where the task is low-volume, high-stakes, and judgment-bound. Pricing a complex contract, choosing a market to enter, deciding who to hire. The model drafts. A person decides.

The infrastructure companies like Together AI are the picks and shovels for the first category. Their value grows as more portfolio companies find the places where probabilistic output is good enough. That adoption curve, not the funding round, is the thing worth tracking.

Reading the round without the hype

Strip the announcement down and three facts remain.

First, serious investors believe open-model infrastructure is a standalone market. That belief funds capacity.

Second, the company's success depends on utilization economics that the round does not disclose and the market cannot see from outside. The business compounds only if the hardware stays full.

Third, the round changes nothing about the hard questions. Switching costs, hyperscaler competition, and the long-run margin of open inference are still open. Capital buys time to answer them, not the answers themselves.

For a fund, the discipline is to treat the round as weather, not climate. It tells you the conditions this quarter. It does not tell you where the coast ends up.

The operator's takeaway

I watch rounds like Together AI's for what they reveal about demand for the layer beneath the applications we back. The number is a signal of conviction, priced by people with more capital than certainty.

AI has already changed how we read that signal, how we test the claims underneath it, and how we help the right portfolio companies build on this kind of infrastructure. It has not changed the questions that decide whether any of it compounds.

The round is a beginning. The work is what comes after it.

FCRA Adverse Action: Shipping AI Without Compliance Debt

Blake Aber — Tue, 06 Oct 2026 19:15:22 +0000

An AI decision engine that can't explain a denial is a liability pretending to be a feature.

Blake Aber · Predicate Ventures · 2026

The constraint is older than the model

Teams building credit decisioning tend to treat adverse-action requirements as a late-stage legal review. That ordering is backwards. The requirement to explain a denial shapes what kind of model you can ship, and it should be fixed before training begins.

Under Regulation B, which implements the Equal Credit Opportunity Act, a creditor must notify an applicant of action taken within 30 days of receiving a completed application, including adverse action. 12 CFR Part 1002. When a counteroffer is extended and the applicant neither accepts nor uses the credit, the window extends to 90 days. 12 CFR Part 1002.

These are not soft targets. They are dated obligations that your system has to meet for every decision it touches, including the ones a model made at 3 a.m. with no human in the loop.

Explainability is a product requirement, not a research goal

The hard part is not sending a notice on time. It is stating the specific reasons the application was denied.

The CFPB addressed this directly in Circular 2022-03, which affirmed that creditors must comply with adverse-action requirements even when complex algorithms make it difficult or impossible to identify the specific reasons for a denial. Circular 2022-03. The guidance drew a clear line: model complexity is not a defense.

That circular, along with Circular 2023-03, was withdrawn on May 12, 2025, as part of a broad removal of CFPB guidance documents. Withdrawn Guidance.

Withdrawal of the guidance does not withdraw the statute. ECOA and Regulation B still require specific-reason disclosure. The circulars articulated an interpretation that an opaque model is not a shield; the underlying legal requirement that produced that interpretation is unchanged. Designing as if explanations are mandatory remains the defensible choice.

What "specific reasons" demands of your architecture

A reason like "your score was too low" does not satisfy the requirement. The applicant needs the actual factors: income relative to obligations, length of credit history, recent delinquencies.

This rules out any design where feature attribution is an afterthought bolted onto a black box. The attribution method has to be reliable enough that the reasons you disclose actually reflect the decision the model made. If your explanation layer and your scoring layer can disagree, you have a compliance gap disguised as a dashboard.

Two workable paths exist. Use models that are inherently interpretable, where the contribution of each input is readable from the model structure. Or use a flexible model paired with an attribution method you have validated against ground truth, so the stated reasons match the mechanism. Either way, the reason-generation step is part of the model, not downstream of it.

Audit trails are the difference between a decision and a claim

A decision your system cannot reconstruct did not happen in any way a regulator will accept.

Regulation B requires creditors to retain, for 25 months, any written or recorded material related to a consumer credit application, including copies of the notification of action taken and the statement of specific reasons for adverse action. Supporting Statement, Regulation B.

For an AI system, retention means more than storing the output. To defend a decision 24 months later, you need the input features as they existed at decision time, the model version that scored them, the reasons generated, and the notice sent. If a model has been retrained three times since, the record has to point to the exact version that produced the result.

Design the record first

Log the decision as an immutable record at the moment it is made. Version every model and every feature transformation, and bind the decision to those versions. Store the generated reasons alongside the score, not reconstructed on demand from a model that may have changed.

The cost of skipping this is not a missing log. It is the inability to prove what your system did, which under a 25-month retention regime is a standing liability for every decision you ever shipped.

Regulator-ready design is cheaper than compliance debt

The debt accrues when explainability and audit are retrofitted after a model is in production. By then the model was chosen for accuracy alone, the attribution layer is an approximation nobody validated, and the logs capture outputs but not the inputs or versions behind them.

Unwinding that is expensive. You end up re-architecting the decision path, re-validating attribution, and backfilling records you never captured. Some of it cannot be backfilled, because the state that produced past decisions is gone.

The alternative is to treat four requirements as fixed constraints before training:

Every decision produces specific, accurate reasons tied to the inputs.
Those reasons are generated by the same process that made the decision.
Every decision is logged immutably with its model version and feature state.
Notices meet the 30-day and 90-day windows automatically.

These constraints narrow your modeling choices. That narrowing is the point. A model you cannot explain is a model you cannot ship in this product, so it should not be a candidate.

The regulatory floor will move; build above it

The May 2025 withdrawals show that guidance is not stable. Interpretations are issued and rescinded, and the posture of any given regulator shifts with administrations.

The statutes move more slowly. ECOA and Regulation B have required specific-reason adverse-action notices for decades, and that requirement survived the withdrawal of the circulars that interpreted it for AI. A system built to the statutory floor stays compliant across guidance changes.

Building to the floor also builds trust with the person on the other end of the decision. An applicant who receives accurate, specific reasons for a denial can act on them. An applicant who receives a vague score has been given nothing. The design that satisfies the regulator is the one that treats the applicant as someone owed an explanation, which is what the law assumed all along.

Multi Agent Orchestration in Production

Blake Aber — Mon, 05 Oct 2026 17:52:13 +0000

Most multi agent systems fail not because the models are weak, but because the orchestration around them is undisciplined.

Blake Aber · Predicate Ventures

Multi agent orchestration is the practice of coordinating several specialized agents to complete work that a single prompt cannot. The demos look clean. The production systems rarely do.

This article covers what actually matters once agents leave the notebook: how to structure coordination, how to measure whether it works, how to contain damage, and where the costs and failures hide.

What orchestration actually means

An agent is a model plus tools plus a loop. Orchestration is the layer that decides which agents run, in what order, with what context, and when to stop.

The mistake is treating orchestration as prompt arrangement. It is control flow. The same engineering rigor you apply to distributed systems applies here, because that is what you are building.

Three structures cover most real work.

Supervisor-worker

A supervisor agent receives the task, decomposes it, and routes subtasks to workers. Workers return results; the supervisor composes the final answer.

This is the default for good reason. Routing logic lives in one place, so you can inspect and constrain it. The failure mode is a supervisor that hallucinates subtasks or loops on the same decomposition.

Pipeline

Agents run in a fixed sequence, each consuming the prior output. A research agent feeds a drafting agent feeds a review agent.

Pipelines are predictable and cheap to reason about. They break when a stage silently degrades and downstream agents treat garbage as signal. Validation between stages is not optional.

Blackboard

Agents read and write to shared state, acting when they see something they can advance. This suits open-ended problems with no clear task order.

It is also the hardest to debug. Shared mutable state across autonomous actors produces race conditions and nondeterminism that are painful to reproduce.

Start with supervisor-worker or pipeline. Reach for blackboard only when the problem genuinely resists sequencing.

Context is the real bottleneck

Agents coordinate through context. The question is how much each agent sees and how that context is assembled.

Two patterns dominate.

Full context sharing passes the entire history to every agent. It preserves information but inflates token cost and introduces noise. By the fifth hop, an agent is reading four irrelevant conversations.

Scoped context gives each agent only what its task requires. This is cheaper and more accurate, but it demands that the orchestrator know what each agent needs. That knowledge is itself engineering work.

Most reliable systems use scoped context with explicit handoffs. The orchestrator writes a clean task specification for each agent rather than forwarding a growing transcript.

Treat the handoff as an API contract. Define what goes in, what comes out, and what the receiver is allowed to assume.

Evaluation before scale

You cannot improve what you cannot measure, and multi agent systems resist measurement because failure is distributed. The final answer is wrong, but which agent caused it?

Build evaluation at two levels.

Component evaluation

Test each agent in isolation against fixed inputs. The research agent gets a query; you check its output against known-good results. This isolates capability from coordination.

Component tests are fast and cheap, and they catch regressions when you swap a model or edit a prompt.

Trajectory evaluation

Test the full run. Did the system reach the right outcome, and did it get there by a reasonable path? A system that produces the right answer through ten wasted agent calls is still broken.

Trajectory evaluation requires logging every agent decision, tool call, and handoff. Instrument this from day one. Retrofitting observability into an agent system is expensive and incomplete.

Score trajectories on outcome, path efficiency, and cost. All three move together in a healthy system.

Guardrails that hold

Autonomous agents acting through tools can do real damage. A pipeline that writes to production, sends messages, or spends money needs limits that do not depend on the model behaving.

Put guardrails outside the agent.

Tool-level constraints bound what any agent can do regardless of what it decides. An agent with database access gets read-only credentials unless a write is explicitly authorized. The permission lives in infrastructure, not in a prompt instruction.

Step and budget limits cap how many actions a run can take and how much it can spend. An agent stuck in a loop hits the ceiling and stops instead of running until someone notices the bill.

Human checkpoints gate irreversible actions. The agent proposes; a person approves. Place these at the small number of points where a mistake is costly and hard to undo.

Guardrails written as prompt instructions are suggestions. Guardrails written as code are constraints.

Cost is an architecture decision

Multi agent systems multiply token usage. A supervisor coordinating five workers across three rounds can issue dozens of model calls for one user request. The cost is not linear in the task; it is a function of the orchestration shape.

Three levers control it.

Match model size to task. Use a small model for routing and extraction, a large one only where reasoning depth earns its price. Running every agent on the largest model is the most common source of waste.

Cache aggressively. Repeated context across agents and runs is a candidate for prompt caching. The savings compound in systems that reuse system prompts and tool definitions.

Cut unnecessary hops. Every additional agent is additional cost and additional failure surface. If two agents can be one without losing clarity, make them one.

Failure modes to design against

Some failures recur across nearly every multi agent system.

Cascading errors, where one agent's mistake becomes the next agent's premise. Validation between stages contains this.

Infinite loops, where agents hand work back and forth without progress. Step limits and loop detection stop it.

Context drift, where the accumulated history pulls agents away from the original goal. Scoped context and explicit task specs reduce it.

Confident wrongness, where a failed agent returns a plausible answer instead of signaling failure. Require agents to report confidence and to fail loudly when they cannot complete a task.

The discipline is the same in every case: assume each agent will fail, and build the orchestration so that failure is detected, contained, and recoverable.

The shape of a working system

A multi agent system that survives production tends to look modest. Few agents, clear roles, scoped context, constraints in code, and instrumentation on every decision.

The impressive demos add agents. The durable systems remove them. Orchestration quality, not agent count, decides whether the thing works.

How VCs and PE Firms Are Actually Using AI

Blake Aber — Mon, 28 Sep 2026 17:24:35 +0000

AI is changing a few specific parts of how funds operate—and leaving most of the job untouched.

Blake Aber · Predicate Ventures · 2026

The question of how venture capitalists and private equity firms use AI usually gets answered by people selling something. Vendors describe a fund where deals source themselves and diligence runs on autopilot. That fund does not exist.

What does exist is narrower and more useful. AI is measurably changing a handful of tasks inside funds, mostly on the operations side, and having almost no effect on others. The difference between the two is worth being precise about.

Where AI is doing real work

The clearest results come from portfolio operations at large PE firms, not from investment decisions.

Apollo built a proprietary AI system that analyzed 15,000 software purchase agreements across its portfolio in minutes, which let one portfolio company cut procurement costs by more than 65% (MIT Sloan Management Review). The mechanism is simple. When you own many companies, they buy many of the same things at different prices, and nobody has ever compared the invoices.

Apollo's system compares purchasing contracts and invoices across more than 40 portfolio companies to find the best price paid for a given product (MIT Sloan Management Review). PitchBook reported a concrete example: the firm found that doormats were being bought across its hospitality holdings at very different prices, then negotiated portfolio-wide contracts (PitchBook).

This is the part vendors get wrong. The value here is not intelligence. It is scale of comparison. A person could find the doormat discrepancy given enough time and access to every invoice. No person has that time or access. AI reads all of it at once, and the return comes from the reading, not from any judgment.

AI inside the portfolio companies

The second category of real results is AI deployed operationally within portfolio companies, where the fund pushes capability down rather than running it centrally.

At Apollo portfolio company Cengage, AI process automation cut content production costs by 40% and lead generation costs by 20% (MIT Sloan). At Yahoo, AI-generated code improved engineering productivity by more than 20% (MIT Sloan).

These are operational gains at the company level. The fund's role is to identify the opportunity, fund it, and repeat the pattern across holdings. That repetition is the actual product of a large firm's AI effort—a playbook applied many times, not a single clever model.

Notice what these examples share. Content production, lead generation, and code generation are all high-volume tasks with clear inputs and outputs. AI performs well where the task is repetitive and the correct answer is verifiable. It performs poorly everywhere else.

Where AI is not changing much

The investment decision itself is largely untouched, and the claims that it is deserve skepticism.

Sourcing is the most common pitch. AI can rank companies by growth signals, hiring data, and web traffic, which is genuinely useful for building a top-of-funnel list. But sourcing was never the binding constraint at most funds. The constraint is winning the allocation and being right about the outcome. AI does neither.

Diligence is the second pitch. Language models summarize data rooms, extract terms from contracts, and flag inconsistencies. This saves associate hours, and saved hours are real. It does not tell you whether a founder will execute, whether a market will hold, or whether a management team will fracture under pressure. Those judgments carry the return, and they remain human.

The pattern is consistent. AI compresses the cost of reading and processing. It does not produce conviction. A fund that confuses the two will automate its analysts and keep making the same picking errors, faster.

The asymmetry between VC and PE

The evidence so far skews toward private equity, and that is not an accident.

PE firms own controlling stakes in many mature companies with real operating expenses. That gives them two things AI needs: authority to change how a business runs, and enough volume for comparison to matter. Apollo's procurement work depends on both.

Venture funds have neither in the same measure. They hold minority stakes in young companies, and they cannot dictate a portfolio company's software contracts. Their AI use tends to sit in their own operations—deal screening, portfolio monitoring, reporting—where the gains are quieter and harder to measure.

This means the honest answer to the keyword question splits by asset class. PE is finding measurable cost savings through portfolio-wide comparison and operational deployment. VC is mostly speeding up back-office work and building better lists.

What an operator should actually do

If you run a fund, the useful moves follow from the evidence rather than the marketing.

Start with tasks that are high-volume, repetitive, and verifiable. Contract analysis across a portfolio qualifies. Reading every invoice qualifies. Summarizing standardized documents qualifies. These are where the Apollo-style returns come from, and they require ownership scale to pay off.

Be honest about what you own. If you hold minority positions, portfolio-wide procurement is not available to you. Point your AI spend at your own operations and at helping companies help themselves, which is closer to the Cengage and Yahoo model than the doormat model.

Do not automate judgment. Use AI to give your team more time and cleaner inputs, then spend that time on the decisions that determine returns. The moment a tool promises to replace conviction, treat the promise as the tell.

The short version

Venture capitalists and private equity firms are using AI in two places that work and one place that mostly does not.

The two that work: reading and comparing high-volume documents at portfolio scale, and deploying operational automation inside owned companies. Both depend on scale and verifiable tasks, which is why PE shows the strongest numbers.

The one that does not: the investment judgment itself. AI makes the surrounding work cheaper. It does not make the pick better. Funds that keep those two ideas separate will get value from AI. Funds that blur them will get speed and call it insight.

FDA AI Regulation: What Evidence Regulators Expect

Blake Aber — Mon, 28 Sep 2026 17:24:34 +0000

Most FDA-cleared AI devices reach the market without demographic data, outcome evidence, or a single randomized trial — and that gap is where liability lives.

Blake Aber · Predicate Ventures · 2026

The market is large and the evidence is thin

The FDA has authorized more than 1,600 AI-enabled medical devices for marketing in the United States as of September 2026. That number reads like maturity. The underlying evidence does not.

Among 691 FDA-cleared AI/ML devices, study design went unreported 46.7% of the time. Training sample size was unreported for 53.3%. Demographic representation was unreported for 95.5%. Only 6 devices, or 1.6%, reported randomized clinical trial data. Three reported patient outcomes.

So a product can be cleared, marketed, and deployed at scale without the public record ever showing who it was trained on or whether it improved a single patient's health. That is the environment teams build in when they build AI for regulated care.

Why the pathway shapes the evidence

The reporting gap is not an accident. It follows from how most devices get cleared.

Of the 168 ML-enabled devices the FDA authorized in 2024, 159 (94.6%) went through the 510(k) pathway, and only 9 (5.4%) through De Novo. The 510(k) route asks a sponsor to show that a new device is substantially equivalent to a legally marketed predicate. It does not, by design, demand fresh clinical trials.

Equivalence to a predicate is a comparison to an existing product, not proof of benefit to a patient. For software that learns from data, that comparison can obscure more than it reveals. Two models can share an intended use and diverge sharply on the populations they handle well.

Radiology dominated 2024 clearances at 74.4%, followed by cardiovascular at 6.5% and neurology at 6.0%. Non-US sponsors accounted for 57.7% of clearances. A model trained on foreign populations, cleared by equivalence, and deployed on US patients carries a validation question that the clearance itself does not answer.

What regulators expect, and what courts will ask

Clearance is a floor, not a shield. The FDA's authorization tells you a device may be marketed. It does not tell a jury that your specific deployment was reasonable.

When an AI recommendation contributes to harm, the questions come in a predictable order.

First: did the device perform as validated on a population resembling the patient? Given that 95.5% of cleared devices report no demographic data, a defendant may have nothing in the public record to answer with. That silence becomes the plaintiff's argument.

Second: did the deployer monitor performance after installation? A model that was accurate at clearance can drift as clinical practice, imaging equipment, or patient mix changes. The absence of monitoring is easier to prove than the presence of harm.

Third: who decided, the software or the clinician? Liability tends to follow the party with the last meaningful choice. Systems that automate away human judgment concentrate risk on the deployer.

Build the record you will need

The defensible position is documentary. Keep the evidence you would want to produce if a regulator or a court asked for it two years after deployment.

That means recording which model version made which recommendation, what data it saw, and what the clinician did with it. It means capturing performance metrics against your own patient population, not only the sponsor's claims. It means a written escalation path for cases where the model's confidence is low or its output conflicts with clinical judgment.

None of this is exotic. It is ordinary engineering discipline applied to a setting where the cost of not having it is measured in patients and litigation.

Privacy is a second regulator sitting at the table

The FDA governs safety and effectiveness. It does not govern how you handle the patient data your model runs on. Two frameworks apply at once, and satisfying one does not satisfy the other.

Training data, inference data, and audit logs are all protected health information the moment they touch a patient. A model that logs its inputs for the sake of the liability record described above has created a new store of sensitive data that must be secured, access-controlled, and retained under its own rules.

The tension is real. Good validation practice pushes you to keep more data. Privacy practice pushes you to keep less. The resolution is scope: keep what you can defend keeping, minimize the rest, and document why each decision was made.

Vendors complicate this further. When a non-US sponsor built the model, the data flows and the contractual terms governing them deserve the same scrutiny as the clearance. A model you did not train is a supply chain, and supply chains carry obligations you inherit whether or not you inspected them.

How to deploy where the stakes are personal

The pattern across all of this is the same. The regulatory clearance is the beginning of your responsibility, not the end of it.

Start by reading the clearance critically. Find the intended use, the predicate lineage, and whatever the sponsor did report about study design and population. Where the record is silent, treat the silence as a question you must answer yourself before deployment.

Validate against your own population before you trust the vendor's numbers. If the model was cleared by equivalence rather than trial, the burden of showing it works on your patients falls on you.

Instrument the deployment so that the record exists before you need it. Version, log, and monitor. Assume that one day someone will ask what happened and why, and build so that you can answer.

Keep a human in the decision where the harm would be personal. The last meaningful choice is where the law looks, and it should be a place where judgment lives.

The volume of cleared AI devices will keep rising. The evidence supporting each one will remain uneven. Teams that treat clearance as permission to stop thinking will find that the thin public record becomes their thin defense. Teams that build their own evidence will be ready for the questions that clearance was never designed to answer.

ECOA Adverse Action Notice: Shipping AI Safely

Blake Aber — Sun, 27 Sep 2026 16:01:33 +0000

An AI credit model is only shippable if it can name the specific reason it said no.

Blake Aber · Predicate Ventures · 2026

The hard part of putting a model behind a lending decision is not accuracy. It is the letter you have to send when the answer is no.

The Equal Credit Opportunity Act and Regulation B require creditors to give applicants a written statement of specific reasons when they take adverse action. Those requirements apply to every credit decision, regardless of the technology that produced it. A model does not get a compliance discount for being complicated.

What the notice actually requires

Regulation B is precise about what counts. The statement of reasons must be specific and indicate the principal reason or reasons for the decision. Saying the action was based on internal standards, general policies, or a failure to reach a qualifying credit score does not satisfy the rule.

The timing is fixed too. A notice of adverse action must generally be given within 30 days after a completed application. A creditor making a counteroffer has 90 days to send the notice if the applicant declines it. Regulation B sets both windows.

There is a narrower path for large business applicants. For business credit applicants with gross revenues over $1 million, the creditor may give notice orally or in writing within a reasonable time, and must provide a written statement of reasons only if the applicant requests it within 60 days. That exception is defined in Part 1002. It does not extend to consumer lending.

The black-box problem is a design constraint

The CFPB has been direct. ECOA and Regulation B do not permit creditors to use complex algorithms when doing so means they cannot state specific and accurate reasons for an adverse action.

Read that as an engineering requirement, not a legal footnote. If your model cannot produce a faithful, decision-level explanation, you cannot legally deploy it for credit. Explainability moves from a nice-to-have into a gate that a model must clear before it reaches production.

The follow-up guidance closed a common shortcut. In Circular 2023-03, issued September 19, 2023, the CFPB said creditors using AI or complex credit models may not rely on the checklist of sample reasons in the Regulation B sample forms if those reasons do not specifically and accurately identify the actual reasons for the decision.

So the sample forms are a starting vocabulary, not a safe harbor. A team that maps every denial to "insufficient credit history" because it is on the list, when the model actually keyed on something else, has produced an inaccurate notice.

One more trap. Disclosing the key factors that adversely affected a consumer's credit score does not by itself satisfy the ECOA requirement to disclose specific reasons for adverse action. Credit-score reason codes and adverse-action reasons are different obligations. Shipping the former and calling it done leaves a gap.

What non-compliance costs

The exposure is concrete. ECOA provides for punitive damages of up to $10,000 in individual lawsuits, and up to the lesser of $500,000 or 1 percent of the creditor's net worth in class actions, on top of actual damages.

A class action is the shape that matters for a model. A single denial letter with a wrong reason is a defect. The same defect across a population of applicants, produced by the same model, is a class. Systematic errors scale the same way the system does.

Designing for the notice from day one

The cheapest time to build adverse-action reasoning is before the model ships. Retrofitting explanations onto a system that was optimized only for accuracy is where compliance debt accumulates.

Make explanations part of the prediction

Every scored decision should emit the score and the reasons together, in the same call. The reasons should be derived from the features the model actually used, weighted by their contribution to that specific decision. If your explanation method cannot answer "why this applicant, not the average one," it is not producing an adverse-action reason.

Favor model architectures and attribution methods whose outputs you can defend to an examiner. A per-decision explanation you cannot reproduce or reason about is worse than a simpler model you can.

Map reasons to language that is specific and true

The reason a model produces internally is a feature and a direction. The reason on the letter is a sentence a person reads. The mapping between them is a controlled artifact.

Build that mapping so each phrase is accurate for the decision it describes, and version it. When the model changes, the reason mapping is part of what gets re-reviewed. Do not let the letter drift from the model.

Keep an audit trail that reconstructs the decision

For any past decision, you should be able to recover the model version, the input features, the score, the reasons emitted, and the notice sent. That record is what turns a regulator inquiry from a fire drill into a query.

Store inputs and outputs together, immutably, keyed to the applicant and the decision. The 30-day notice window and the 60-day business-request window both assume you can find the decision later. An audit trail that cannot reconstruct a specific case is not an audit trail.

Treat the model registry as a compliance record

Every deployed model version should carry its evaluation, its reason mapping, its approval, and the dates it was live. When a class-action question arrives about decisions from a given quarter, you want to name the exact model that made them and produce its documentation without archaeology.

The shippable posture

A credit AI system is regulator-ready when three things are true at once. It produces a specific, accurate reason for every adverse action. It records enough to reconstruct any past decision. And its explanation, reason mapping, and model version move together through review.

None of this is a tax on the model. It is the difference between a system you can defend and a class action waiting to be filed. Build the notice into the architecture, and the letter takes care of itself.

Agent-as-a-Judge: Evaluate Agents With Agents

Blake Aber — Sun, 27 Sep 2026 16:01:32 +0000

Scoring agent behavior with another agent works, but only if you treat the judge as a system component with its own failure modes.

Blake Aber · Predicate Ventures

Why judging agents is harder than judging outputs

Evaluating a single model response is a bounded problem. You have an input, an output, and a rubric. Compare, score, move on.

Agents break that framing. An agent takes multiple steps, calls tools, revises its plan, and produces a trajectory rather than a single answer. The final output can be correct while the path to it was wasteful, unsafe, or accidentally right.

That is the gap agent-as-a-judge fills. Instead of scoring only the last message, you use an evaluator agent that inspects the full trajectory: the reasoning, the tool calls, the intermediate states, and the final result.

The premise is simple. The agent doing the work is not the best-positioned observer of its own behavior. A separate agent, given the trace and a rubric, can catch errors the working agent cannot see.

What the judge actually reads

A useful judge does not receive a summary. It receives the artifact.

That means the full step log: each planning decision, each tool invocation with its arguments, each tool return value, and the state transitions in between. If you only hand the judge the final answer, you have rebuilt output evaluation and lost the reason for using an agent at all.

Concrete inputs to a trajectory judge:

The original task specification and any constraints.
The ordered list of steps the agent took.
Tool call arguments and raw returns, not paraphrases.
The final deliverable.
A rubric that maps to the dimensions you care about.

The rubric matters more than the model. A judge with a vague prompt returns vague scores. A judge with explicit criteria and examples of pass and fail returns something you can act on.

Patterns that hold up in production

Per-step scoring vs. trajectory scoring

Two modes, different uses.

Per-step scoring evaluates each action in isolation: was this tool call valid, was the argument correct, did the step advance the task. This surfaces where a run went wrong.

Trajectory scoring evaluates the run as a whole: did the agent solve the task, was the path efficient, did it respect constraints. This tells you whether the run was good.

Run both. Per-step scoring drives debugging. Trajectory scoring drives the aggregate metrics you report and gate releases on.

Rubric decomposition

A single overall quality score hides too much. Break the rubric into named dimensions and score each separately.

Common dimensions: task completion, tool-use correctness, efficiency, constraint adherence, and safety. When completion is high but efficiency is low, you know the agent is solving the problem the expensive way. A single blended number would have masked that.

Reference-based and reference-free judging

When you have a known-good trajectory or a gold answer, give it to the judge. Reference-based judging is more reliable because the model compares against a fixed target instead of reasoning from scratch.

When you have no reference, which is most of the time in open-ended agent work, the judge scores against the rubric alone. Expect more variance here and account for it.

Pairwise comparison

Asking a judge to score one trajectory on an absolute scale is noisy. Asking it to choose between two trajectories is more stable.

Use pairwise comparison when you are ranking model versions or prompt variants. Use absolute scoring when you need a threshold to gate against.

Failure modes of the judge itself

The judge is an agent. It fails the way agents fail.

Position bias. In pairwise comparison, judges favor whichever trajectory appears first. Swap the order across runs and average. If the winner flips with position, the comparison is not real.

Length bias. Judges reward longer, more detailed trajectories even when brevity was correct. Watch for a correlation between token count and score that your rubric did not intend.

Self-preference. A judge built on the same model family as the worker tends to rate that family's output higher. Cross-family judging reduces this.

Rubric drift. Over many runs, the judge's interpretation of the rubric shifts subtly. Anchor it with fixed few-shot examples and periodically re-validate against human labels.

The last point is the one people skip. A judge that has never been checked against human judgment is an opinion, not a measurement. Calibrate against a labeled set, measure agreement, and re-check when you change the judge prompt or model.

Guardrails are a different job

A judge scores after the fact. A guardrail acts during the run.

Do not conflate them. Judging is evaluation for offline analysis and release gating. Guardrails are runtime checks that block unsafe tool calls, malformed arguments, or actions outside policy before they execute.

A guardrail can be an agent too, running as a fast inline check. But its job is a binary allow or deny on a specific action, not a graded assessment of the whole trajectory. Keep the two separate so a slow, thorough judge never sits in your latency path.

The cost problem

Judging every production run with a full trajectory judge is expensive. The judge reads more tokens than the worker produced, and it runs on top of the work you already paid for.

Control this deliberately.

Sample. Judge a fraction of production traffic, not all of it, once you trust the metric.
Tier the judge. Use a cheap judge for a first pass and escalate only ambiguous cases to a stronger, costlier one.
Judge offline. Move full evaluation out of the request path into batch jobs against logged traces.
Cache references. Reuse gold trajectories across runs instead of regenerating them.

The goal is a signal you can afford to collect continuously, not a one-time benchmark you run before launch and never again.

Where to start

Begin with a rubric written by the people who own the task, not by the model. Decompose it into named dimensions. Feed the judge full trajectories, not summaries.

Then calibrate against human labels before you trust a single number. Measure judge-human agreement, correct for position and length bias, and only then wire the metric into your release process.

Agents that evaluate agents give you a scalable way to watch behavior you cannot review by hand. They earn that trust only after you have treated the judge as carefully as the system it grades.

Model Risk Governance: A Practical Framework

Blake Aber — Tue, 11 Aug 2026 14:51:28 +0000

Model risk governance turns scattered spreadsheets and black-box algorithms into a system someone is accountable for.

Blake Aber · Predicate Ventures · 2026

What model risk governance actually covers

Models drive lending decisions, capital calculations, fraud detection, and pricing. Each one carries the risk of being wrong—wrong by design, wrong in implementation, or wrong because it was applied to a situation it was never built for.

Model risk governance is the discipline that names an owner for that risk and defines how models get built, checked, and retired.

The reference point for most institutions is SR 11-7, the Guidance on Model Risk Management issued by the Federal Reserve jointly with the OCC. It describes an effective framework as covering three areas: model development, implementation, and use; effective validation; and sound governance, policies, and controls.

Those three areas are the outline for everything below.

The three components of a model

Before you can govern a model, you have to agree on what one is.

SR 11-7 defines a model as three parts: an information input component, a processing component, and a reporting component.

Inputs are the data and assumptions that feed the model. Processing is the method that turns inputs into estimates. Reporting is how the output reaches the people who act on it.

This definition matters commercially. It means governance applies to the assumptions and the presentation, not only the equation in the middle. A model can be mathematically sound and still fail because it was fed stale data or because its output was reported in a way that misled the people relying on it.

When firms scope their model inventory, this three-part definition decides what counts. Tools that only produce a number from a fixed formula may not qualify. Tools that estimate, forecast, or approximate almost always do.

Development, implementation, and use

The first area is the model's working life.

Development covers how the model is designed and tested. It includes the rationale for the method chosen, the quality of the data, and documentation good enough that someone other than the builder can understand it.

Implementation is the move from a developer's environment into production systems. This is where errors hide. A model that behaved correctly in testing can break when it is connected to live data feeds or coded into a different platform.

Use is the ongoing application of the model to real decisions. Governance here asks whether the model is still being applied to the conditions it was built for, and whether users understand its limits.

Each stage produces a record. The record is what a validator and an examiner will read.

Validation as an independent check

Validation is the second area, and it is the part most firms underbuild.

Effective validation is independent. The people checking a model should not be the people who built it, because builders are poorly positioned to see their own blind spots.

SR 11-7 recommends a periodic review of each model, at least annually and more often when circumstances warrant, to confirm it is working as intended.

Annual is a floor, not a target. A model tied to volatile markets or rapidly shifting customer behavior may need review every quarter. A stable model in a slow domain may justify the annual minimum. The framework asks the firm to decide the frequency and defend it.

Validation is not a one-time gate at launch. It is a repeated test that a model still fits the world it operates in. Markets move, portfolios change, and a model that was accurate two years ago may now be quietly biased.

What validation should confirm

A useful validation answers a few plain questions. Does the model do what its documentation claims? Are its inputs still appropriate? Do its outputs match reality when checked against outcomes? Are its known weaknesses being managed?

When the answer to any of these is no, the finding goes to the model owner with a timeline for resolution. Findings that sit unresolved are themselves a governance failure.

Governance, policies, and controls

The third area is the structure that holds the other two together.

Governance assigns roles. Someone owns each model. Someone validates it. Someone approves it for use and sets the policy for how often it is reviewed. The board and senior management are responsible for the framework as a whole.

Policies define the rules in writing—what qualifies as a model, how the inventory is maintained, what documentation is required, and how exceptions are handled. Controls are the mechanisms that enforce those rules, including access limits, change management, and monitoring of outputs.

Without this layer, development and validation become one-off efforts that decay. With it, they become a repeatable process an institution can staff, audit, and improve.

The regulatory baseline is settled and current

Model risk governance is not an aspiration a firm invents on its own. Regulators have set a shared standard.

The FDIC adopted the 2011 supervisory guidance as FIL-22-2017, extending the SR 11-7 approach across the institutions it supervises.

More recently, the OCC, Federal Reserve, and FDIC issued revised interagency model risk management guidance, rescinding prior issuances including OCC Bulletin 2011-12. The Federal Reserve published its version of the revised guidance as SR 26-2.

The practical takeaway is that the three-area framework—development and use, validation, and governance—remains the reference standard, now expressed through the current interagency guidance. Firms building or refreshing a program should map to the version in force for their regulator rather than the superseded letters.

Building a program that holds up

A credible model risk governance program is legible. An outsider should be able to open the inventory, pick a model, and trace its development record, its last validation, its owner, and its review schedule.

Start with the inventory. You cannot govern what you have not listed, and most firms discover they own more models than they thought once they apply the three-component definition.

Then set validation independence and cadence. Assign owners. Write the policy. Wire in the controls that catch a model drifting or a change slipping through untested.

The cost of this work is real. The cost of a mispriced portfolio, a failed capital calculation, or an examiner finding is larger, and harder to schedule. Governance is how a firm pays the smaller bill on purpose instead of the larger one by surprise.

AI Risk Management Playbook: A Working Guide

Blake Aber — Mon, 10 Aug 2026 10:20:46 +0000

A working AI risk management playbook turns abstract governance principles into decisions your teams can make on a deadline.

Blake Aber · Predicate Ventures · 2026

Why a playbook, not a policy

Most organizations already have an AI policy. Few have a playbook.

A policy states intent. A playbook states procedure: who decides, on what evidence, by when, and what happens when the answer is no.

The gap matters because AI risk does not announce itself. It surfaces at the moment a model is repurposed, a dataset shifts, or a vendor changes its terms. When those moments arrive, teams need a sequence to follow, not a statement of values to reread.

This playbook uses the four functions of the NIST AI Risk Management Framework as its spine. NIST released AI RMF 1.0 on January 26, 2023, and it has become the common reference for enterprise AI governance in the United States. The four functions—Govern, Map, Measure, Manage—give you named stages to assign owners and checkpoints.

Govern: set the standing rules before anyone builds

Governance is the layer that outlasts individual projects. It answers the questions you should not relitigate every time a new use case appears.

Start with three artifacts.

An inventory

You cannot manage what you have not counted. Maintain a live register of every AI system in use, including third-party tools and features embedded in software you already license. Each entry records the owner, the purpose, the data it touches, and its risk tier.

A risk tiering rule

Not every model deserves the same scrutiny. Define tiers by potential harm—effect on people, on legal exposure, on revenue. A copywriting assistant and a credit-decision model belong in different tiers with different approval paths.

A decision authority

Name who can approve deployment at each tier. Low-tier tools may clear at the team level. High-tier systems require sign-off from a named committee with legal, security, and business representation.

Governance also sets escalation. When a model behaves outside expected bounds, who is paged, and who can pull it from production? Write that down before you need it.

Map: understand the system in its context

Mapping is the diligence stage. Before measurement, you establish what the system is supposed to do and where it can go wrong.

Document the intended use in plain language, then document the foreseeable misuses. A model built to summarize support tickets can be fed adversarial input or asked questions it was never validated for. Naming those paths early tells your testers what to probe.

Map the data lineage. Where does training and input data originate, who owns it, and what constraints attach to it? Data provenance is where many compliance failures begin.

Map dependencies. If your system relies on a third-party foundation model, its behavior can change without your involvement. Record which external components you depend on and what you would do if one degraded or disappeared.

Generative systems carry a distinct set of concerns—hallucination, data leakage, prompt injection, and content provenance among them. NIST addressed these directly in NIST-AI-600-1, the Generative AI Profile released July 26, 2024. Use it as a checklist when the system in question generates text, images, code, or audio.

Measure: test against defined thresholds

Measurement converts concern into evidence. The goal is to replace opinions about a model's safety with results.

Set thresholds before testing. Decide in advance what accuracy, bias, and reliability numbers you will accept. Thresholds set after seeing results tend to bend toward the result you want.

Measure across several dimensions.

Performance: Does the system meet its stated task quality on representative data?
Fairness: Do outcomes differ across groups in ways you cannot justify?
Reliability: Does performance hold when inputs drift from the test set?
Security: Can the system be manipulated through its inputs?

Measurement is not a launch-day event. Models degrade as the world moves away from their training data. Schedule re-measurement at intervals tied to risk tier, and trigger it whenever inputs or dependencies change materially.

Record the results where an auditor could find them. If you cannot show your work later, you did not measure—you guessed.

Manage: act on what you learned

Management is where the playbook earns its name. Measurement produces findings; management assigns responses.

For each identified risk, choose one of four responses and document it: accept, mitigate, transfer, or avoid. Accepting a risk is legitimate—if it is a decision, made by someone with authority, and recorded.

Mitigation is the common path. It includes technical controls such as input filtering and output review, and process controls such as human sign-off for high-stakes decisions. Match the control to the harm you mapped.

Build monitoring into production, not around it. The system should report on its own behavior—drift, error rates, unusual inputs—so problems surface in dashboards rather than in complaints.

Keep a response plan for failures. When a model produces harmful output, the sequence should be known: contain, assess, notify, remediate, record. Rehearsed response separates an incident from a crisis.

Making the playbook durable

The framework underneath this playbook is not static. NIST plans to review the AI RMF with formal community input no later than 2028, and the technology will move faster than that. Treat your playbook as a document that gets versioned, not one that gets finished.

Two practices keep it alive.

First, assign an owner. A playbook without an owner drifts into obsolescence within a quarter. Someone should be accountable for updating it as tools, regulations, and incidents accumulate.

Second, run it on real cases. A playbook that has never been used against a live deployment is theory. The first few times you apply it, you will find gaps—steps that are unclear, owners who were never told, thresholds nobody agreed to. Fix them while the stakes are low.

The organizations that handle AI risk well are rarely the ones with the longest policy documents. They are the ones whose teams know what to do when a model does something unexpected—and can show why they made the call they did.

Why VC Firms Invest in AI Startups Now

Blake Aber — Mon, 10 Aug 2026 10:20:45 +0000

The share of venture dollars going to AI has doubled in three years, and the concentration is now impossible to ignore.

Blake Aber · Predicate Ventures · 2026

The scale of the shift

AI firms made up 61% of all global VC investment in 2025, up from 30% in 2022, per the OECD. That is a doubling of share in three years.

The dollar figures match the percentages. VCs put $192.7 billion into AI startups in 2025 through Q3, according to PitchBook data reported by Bloomberg. That pace put 2025 on track to be the first year where more than half of all VC dollars went to AI.

When a single category crosses half of an entire asset class, it stops being a theme and becomes the market itself.

Why VC firms are concentrating on AI

Three forces explain the concentration.

The first is model performance. Capabilities that were research demos in 2022 became shippable products by 2025. Investors fund what customers will pay for, and paying customers arrived.

The second is defensibility questions. Firms are trying to identify which AI startups own something durable versus which are thin wrappers on someone else's model. That question sends money toward companies with data advantages, distribution, or infrastructure ownership.

The third is fund math. When one category compounds faster than the rest of a portfolio, partners feel pressure to keep pace. A fund that skips AI risks underperforming its peers on paper, even before returns are realized.

Where the money actually goes

The headline share hides an uneven distribution.

AI firms working on IT infrastructure and hosting attracted the most VC investment, reaching $109.3 billion in 2025, per the OECD. That single infrastructure layer accounts for $109.3 billion, more than half of the $192.7 billion figure.

The pattern tells you something about how VC firms invest in AI startups. The largest checks flow to the companies building the compute, hosting, and foundational systems that everything else runs on. Application-layer startups compete for the remainder.

For founders, this means the fundraising experience differs sharply by layer. Infrastructure companies raise large rounds against large capital needs. Application companies raise against traction and margins.

How to read the concentration as an investor

A market where one category takes 61% of dollars carries two readings, and both are worth holding at once.

The optimistic reading: AI is a general-purpose capability, and capital is repricing entire industries around it. Under this view, the concentration reflects genuine opportunity rather than crowding.

The cautious reading: capital concentration this fast tends to compress returns. When most funds chase the same category, entry valuations rise and future multiples fall. The winners may be real while the average outcome disappoints.

Neither reading requires predicting a crash. Both suggest discipline on price and a clear thesis about which layer of the stack a given check belongs in.

Questions that separate the checks

Before committing to an AI startup, a firm should be able to answer a few things plainly.

What does this company own that a model provider could not replicate? Data, distribution, workflow lock-in, or regulatory position are the usual candidates.

What is the gross margin after inference costs? Some AI products carry compute costs that erode the margins investors expect from software.

Which layer is this, and does the check size match the layer? Infrastructure and application companies have different capital profiles, and mismatches show up later as down rounds.

What this means for founders raising now

The environment is generous to AI founders in one sense and demanding in another.

Capital is available. With more than half of VC dollars aimed at AI, a credible AI startup has more funding options than a comparable non-AI company.

But availability raises the bar. When many companies pitch similar capabilities, investors filter harder on defensibility and unit economics. A founder who cannot articulate what stays proprietary as models improve will struggle, regardless of how much capital is in the market.

The practical move is to raise against a specific advantage rather than against the category. "We do AI" is no longer a differentiator when 61% of the market does too.

The durability question

The honest uncertainty is how long this share persists.

A doubling from 30% to 61% in three years is not a trend that can continue at the same rate, because the ceiling is 100%. At some point the share stabilizes or reverts.

What happens next depends on returns. If early AI investments return capital at rates that justify the concentration, allocators keep the weighting. If they do not, capital rotates and the share falls.

The OECD and PitchBook figures describe where money went, not where it will earn. That distinction matters. Investment share is a measure of conviction, and conviction is priced before it is proven.

The takeaway

VC firms invest in AI startups at a level without precedent in the asset class. The $192.7 billion figure and the 61% share both point to the same fact: AI is now the center of gravity for venture capital, not a segment of it.

The useful response is neither enthusiasm nor skepticism but specificity. Know which layer a company sits in. Know what it owns. Know whether the check size fits the capital profile.

The firms that do well in this cycle will be the ones that treated a 61% market share as a reason for discipline rather than a reason to relax it.

Operational Due Diligence: A Practical Guide

Blake Aber — Tue, 04 Aug 2026 16:08:12 +0000

Operational due diligence measures whether a fund can run its business, not whether it can pick investments.

Blake Aber · Predicate Ventures

What operational due diligence covers

Investment due diligence asks whether a manager can generate returns. Operational due diligence asks whether the firm can hold the assets, price them honestly, move cash safely, and keep records that survive an audit.

These are separate questions. A fund can post strong numbers while running a back office that would collapse under a redemption wave or a regulatory inquiry. Allocators who skip the operational review learn this the hard way.

The discipline grew out of failures where the strategy was fine but the plumbing was not. Fraud, misvaluation, and cash controls that let one person move money without a second signature — these are operational failures, not investment failures.

Why allocators run it separately

Most institutional allocators keep operational due diligence in a different team than investment analysis. The separation is deliberate.

Investment analysts want the deal to close. They build relationships with managers and grow attached to a thesis. Operational reviewers hold veto power precisely because they carry no incentive to say yes.

At many pensions, endowments, and funds of funds, the operational team can kill an allocation the investment team loves. That structure exists because the two functions pull in opposite directions, and the allocator wants both pressures represented before capital moves.

The core areas under review

Valuation

How does the fund price its positions? Liquid securities are simple. The scrutiny goes to illiquid or hard-to-mark assets, where the manager has discretion over the number that determines its fees.

Reviewers check whether valuation involves an independent party, whether the methodology is documented, and whether the manager can override the process. A fund that marks its own illiquid book with no external check is a warning sign.

Cash controls

Who can move money, and who approves it? The standard is separation of duties: no single person should be able to initiate and authorize a wire.

Reviewers trace the wire process end to end. They confirm that outgoing payments require dual authorization and that account changes trigger callback verification. Most large fund frauds trace back to a manager who controlled cash movement without oversight.

Service providers

The administrator, auditor, custodian, and prime broker form an external check on the manager's claims. Their quality matters.

Reviewers confirm that the administrator is independent and calculates the fund's net asset value rather than rubber-stamping the manager's figures. They verify the auditor is a recognized firm and that the audit opinion is clean. A name-brand administrator on paper means little if the manager still produces the numbers internally.

Compliance and legal

Who handles regulatory filings? Is there a compliance officer, and does that person have authority independent of the portfolio managers?

Reviewers examine the firm's regulatory history, past examinations, and any litigation. They read the fund documents for terms that shift risk to investors — gates, side pockets, suspension rights — and confirm those terms are disclosed and used consistently.

Technology and business continuity

What systems run the trading, accounting, and reconciliation? Are they enterprise tools or spreadsheets held together by one employee?

Reviewers ask about disaster recovery, data backups, and cybersecurity. A fund that cannot operate if its office loses power, or that stores investor data without protection, carries operational risk regardless of returns.

How the review runs

Operational due diligence usually starts with a document request. The manager sends financial statements, service provider agreements, compliance manuals, valuation policies, and organizational charts.

An on-site visit follows. Reviewers want to see the office, meet the operations staff, and observe how the firm actually functions rather than how the pitch deck describes it. Meeting the chief operating officer and the compliance officer in person reveals whether those roles exist in substance or only on the org chart.

Reference calls close the loop. Reviewers contact the administrator, the auditor, and sometimes former employees. Independent confirmation of the manager's claims carries more weight than the manager's own account.

What separates a pass from a fail

No fund is perfect. The question is whether weaknesses are structural or manageable.

A small fund running lean is acceptable if the controls that matter are in place. A large fund with poor cash separation is not, regardless of size. Reviewers weigh severity, not the length of the deficiency list.

The hard veto categories tend to be consistent: no independent administrator, no clean audit, valuation controlled entirely by the manager, and cash movement without separation of duties. Any one of these can end an allocation.

Softer findings — outdated policy documents, thin staffing, dependence on a single key person — usually generate conditions rather than rejections. The allocator asks the manager to fix the issue or accepts a monitoring arrangement.

Ongoing review

Operational due diligence is not a one-time gate. Funds change. Staff leave, service providers get swapped, and controls that held at onboarding can erode.

Allocators re-run the review periodically, often annually for material positions. They watch for turnover in the operations team, changes to the auditor, and any restatement of past figures. A manager who switches administrators quietly, or whose chief financial officer departs abruptly, warrants a fresh look.

For managers raising capital

Managers who understand what allocators test can prepare for it. The operational review is winnable when the firm treats its back office as seriously as its investment process.

Hire an independent administrator early. Engage a recognized auditor. Document the valuation policy and follow it. Build cash controls with real separation of duties before an allocator asks.

The managers who fail operational due diligence rarely do so because they cannot afford controls. They fail because they treated operations as overhead and never built the structure a serious allocator expects to find.

A clean operational review does not win an allocation on its own. But a failed one ends the conversation, no matter how good the returns look.

AI Governance Consulting: What to Buy and Why

Blake Aber — Mon, 03 Aug 2026 12:25:30 +0000

AI governance consulting is worth buying when it produces controls people follow, not documents auditors file.

Blake Aber · Predicate Ventures · 2026

What the market is actually selling

Most AI governance consulting engagements promise the same three deliverables: a risk register, a policy set, and a control framework mapped to a recognized standard.

The quality gap is enormous. Two firms can deliver identical-looking artifacts, and one leaves you with rules that shape how models get built and shipped while the other leaves you with a PDF nobody opens.

The difference is not the framework. It is whether the framework was translated into decisions your teams make every week.

The standard everyone maps to

The reference point for most engagements is the NIST AI Risk Management Framework, released January 26, 2023. AI Risk Management Framework | NIST

The AI RMF organizes work into four functions: Govern, Map, Measure, and Manage. It is voluntary and sector-neutral, which is why consultants like it — it gives structure without prescribing controls that might not fit your business.

NIST followed the framework with the Trustworthy and Responsible AI Resource Center on March 30, 2023, to help organizations put the RMF into practice. AI Risk Management Framework | NIST

If you are deploying generative models, ask specifically about NIST-AI-600-1, the Generative AI Profile released July 26, 2024. AI Risk Management Framework | NIST It addresses risks specific to generative systems, and a consultant who has not read it is selling you 2023.

Where the fee earns out

Governance consulting pays for itself in three places.

Inventory

Most organizations cannot list the AI systems they run. Shadow deployments, vendor features that quietly added a model, and pilots that became production all escape the register.

A good engagement starts by finding what exists, not by writing policy for what should exist. The inventory is the deliverable that surprises executives most, because it usually reveals systems nobody approved.

Risk tiering

Not every model needs the same scrutiny. A demand-forecasting tool and a credit-decision model carry different consequences, and treating them identically wastes effort on one and under-controls the other.

Consultants earn their fee by building a tiering scheme that routes high-consequence systems to review and lets low-stakes tools ship fast. This is the Map function of the AI RMF applied to your actual portfolio.

Control design

The last place value shows up is in controls that fit how your teams already work. Human-review gates, evaluation thresholds, documentation requirements, and monitoring — these only work if they sit inside existing engineering and procurement processes.

A control that requires a new committee meeting will be skipped. A control embedded in a deployment checklist will hold.

How to tell operators from slide decks

The commercial risk in this category is buying advice that never touches production. Here is how to screen.

Ask who implements. If the answer is "we hand off to your team," you are buying a plan, not a system. Firms that stay through implementation have more incentive to design controls that people can follow.

Ask for a sample control, not a sample policy. Policies are generic. A control — the specific gate, the specific threshold, the specific owner — reveals whether the firm thinks about enforcement or just about language.

Ask how they handle model changes. Governance is not a one-time certification. Models get retrained, prompts get edited, vendors push updates. A consultant who cannot describe change management is selling a snapshot of a moving system.

Ask what they measure. The Measure function of the AI RMF is where most engagements go thin, because measurement requires access to model behavior, not just to org charts. Firms that avoid the topic usually cannot do it.

Scope you should insist on

A defensible engagement covers four things.

Governance structure — who owns AI risk, who signs off, and where accountability sits when a model fails. This maps to the Govern function and is where the RMF spends most of its guidance, because structure precedes everything else.

System inventory and tiering — the map of what you run and how much each system matters.

Control library — the actual gates, tied to your development lifecycle rather than to a separate compliance track.

Monitoring and review cadence — how you catch drift, incidents, and vendor changes before they become disclosures.

If a proposal skips inventory or monitoring, it is selling policy and calling it governance.

Build versus buy

Some of this work is worth doing in-house. Inventory, once built, is maintained more cheaply by the teams who own the systems. Control enforcement belongs to engineering permanently.

What consultants add is the initial structure and the outside read on where your exposure sits. They have seen more failure modes than any single company accumulates, and that pattern library is the thing you are actually paying for.

The trap is renting the pattern library forever. Structure the engagement so the framework, the controls, and the review process transfer to your staff. If the consultant becomes a permanent dependency, the governance program is theirs, not yours.

What to pay for

Price the engagement against the deliverables that outlast it: an inventory your team can update, a tiering scheme they understand, and a control set embedded in existing processes.

Do not price it against the length of the policy document. A short policy that governs behavior beats a long one that decorates a shared drive.

AI governance consulting is worth buying when it leaves your organization able to answer three questions without calling the consultant back: what AI do we run, how much does each system matter, and what happens when one of them fails. A firm that gets you there has earned the fee. A firm that hands you a framework and leaves has sold you homework.

DEV Community: Blake Aber

Together AI Funding Round: What It Signals

The round itself

What the capital is actually for

Where this changes a fund's operations

Sourcing and triage

Diligence on infrastructure claims

Where it does not help

What the round signals about the category

Where AI changes portfolio value creation

Reading the round without the hype

The operator's takeaway

Related reading

FCRA Adverse Action: Shipping AI Without Compliance Debt

The constraint is older than the model

Explainability is a product requirement, not a research goal

What "specific reasons" demands of your architecture

Audit trails are the difference between a decision and a claim

Design the record first

Regulator-ready design is cheaper than compliance debt

The regulatory floor will move; build above it

Related reading

Multi Agent Orchestration in Production

What orchestration actually means

Supervisor-worker

Pipeline

Blackboard

Context is the real bottleneck

Evaluation before scale

Component evaluation

Trajectory evaluation

Guardrails that hold

Cost is an architecture decision

Failure modes to design against

The shape of a working system

Related reading

How VCs and PE Firms Are Actually Using AI

Where AI is doing real work

AI inside the portfolio companies

Where AI is not changing much

The asymmetry between VC and PE

What an operator should actually do

The short version

Related reading

FDA AI Regulation: What Evidence Regulators Expect

The market is large and the evidence is thin

Why the pathway shapes the evidence

What regulators expect, and what courts will ask

Build the record you will need

Privacy is a second regulator sitting at the table

How to deploy where the stakes are personal

Related reading

ECOA Adverse Action Notice: Shipping AI Safely

What the notice actually requires

The black-box problem is a design constraint

What non-compliance costs

Designing for the notice from day one

Make explanations part of the prediction

Map reasons to language that is specific and true

Keep an audit trail that reconstructs the decision

Treat the model registry as a compliance record

The shippable posture

Agent-as-a-Judge: Evaluate Agents With Agents

Why judging agents is harder than judging outputs

What the judge actually reads

Patterns that hold up in production

Per-step scoring vs. trajectory scoring

Rubric decomposition

Reference-based and reference-free judging

Pairwise comparison

Failure modes of the judge itself

Guardrails are a different job

The cost problem

Where to start

Model Risk Governance: A Practical Framework

What model risk governance actually covers

The three components of a model

Development, implementation, and use

Validation as an independent check

What validation should confirm