DEV Community: Blake Aber

Post Acquisition Integration: A Field Guide

Blake Aber — Mon, 20 Jul 2026 11:50:31 +0000

Most deals are won at signing and lost in the months that follow.

Blake Aber · Predicate Ventures · 2026

The gap between the deal and the return

Buyers spend months on diligence and price. They spend far less time on what happens after the wire clears.

That imbalance shows up in results. The purchase thesis assumes synergies, retained talent, and combined systems. Integration is where those assumptions get tested against reality.

The volume of deals makes this more pressing. Global M&A deal value in 2025 rebounded to the second-highest total on record, up 36% versus 2024, according to Bain & Company. More transactions means more integrations that either return capital or destroy it.

Why integration difficulty has risen

The kind of deals being done shapes how hard integration is.

Bain reported that scope deals reached a record share of large 2025 transactions, as companies focused on topline growth and new capabilities. Scope deals are harder to integrate than scale deals. You are combining different customers, product lines, and operating rhythms rather than consolidating the same one.

Private equity added to the pressure. McKinsey reported that private-equity-led deal value grew sharply in 2025, outpacing the broader market. PE owners work on defined hold periods, so integration timelines are compressed by design.

Size compounds the challenge. PitchBook reported that megadeals drove 2025 growth, with billion-dollar-plus transactions generating a majority of global M&A value. Larger deals carry more employees, more contracts, and more systems to reconcile.

Start integration before close

The worst integrations begin the day after signing. The best ones begin during diligence.

Diligence should produce more than a valuation. It should produce a list of what will be combined, what will stay separate, and who owns each decision. Treat the data room as the first draft of the integration plan.

Name an integration leader early. This person is not the deal lead. Deal leads are rewarded for closing; integration leaders are rewarded for what happens over the following year. The two skill sets rarely sit in the same person.

Define the operating model before close. Will the acquired company run standalone, fold into the parent, or something between? That single choice drives every downstream decision about systems, reporting, and headcount.

The first 100 days

The opening period sets the tone for everything after it. Employees, customers, and suppliers are all watching to see whether the new owner is competent.

People decisions come first

Uncertainty drives attrition. The people most likely to leave are often the ones you most want to keep, because they have options.

Decide who stays, who leads, and how compensation works, then communicate those decisions quickly. Silence is read as bad news even when the news is neutral.

Retention packages matter for key staff, but they are not a substitute for clarity about roles. People stay for a defined job, not only for a bonus.

Protect the revenue

Customers do not care about your integration plan. They care whether their contract, their contact, and their pricing hold.

Assign clear account ownership on day one. A customer who does not know who to call is a customer a competitor can reach.

Hold pricing and terms steady through the transition unless there is a strong reason not to. Changing commercial terms during integration signals instability at the worst possible moment.

Set a small number of priorities

Integration teams try to do everything at once and finish nothing. Pick the few outcomes that justify the deal and sequence the rest behind them.

If the thesis was cost synergy, name the specific costs and the dates. If it was cross-selling, name the products, the accounts, and the owners.

Systems and data

Technology integration is slower and more expensive than most plans assume. It is also where synergy estimates quietly erode.

Map the systems on both sides early. Overlapping ERP, CRM, and finance tools each carry migration cost and risk.

Resist the urge to consolidate everything immediately. Some systems can wait; forcing a migration before the business is stable creates outages that cost more than the savings.

Data is the harder problem. Customer records, financial history, and product catalogs rarely match cleanly between two companies. Reconciling them takes time and dedicated staff, and it blocks reporting until it is done.

Measuring whether integration worked

Synergy targets set at signing tend to be forgotten by the second quarter. That is how value leaks without anyone noticing.

Track the synergies as line items with owners and dates. If a target was $20 million in cost reduction by a given quarter, it should appear in a report every month against actuals.

Watch attrition among the acquired staff. High turnover in the first year usually means the integration plan asked more than the organization could absorb.

Watch customer retention with the same discipline. Revenue that walks out during integration is the clearest sign the deal is underperforming its thesis.

What separates good buyers

The record-setting deal environment favors buyers who treat integration as a discipline rather than an afterthought. PitchBook reported that 2025 was the most active M&A year on record by both count and value, with deal count up 12.4% year over year. McKinsey reported that 2025 global deal value finished the year up 43%, exceeding the ten-year average.

More activity does not mean more success. It means more chances to get integration wrong.

The buyers who repeat well share a few habits. They plan integration before signing. They put a dedicated leader in charge. They decide the operating model early and communicate it fast. They protect people and revenue in the first hundred days. They track synergies as concrete line items.

None of these habits are complicated. They are simply harder to sustain than to describe, which is why the gap between the deal price and the return persists across cycles.

Acquisition Integration: What Drives Deal Value

Blake Aber — Mon, 20 Jul 2026 11:50:30 +0000

Integration is where deal value is made or lost—and the clock starts at close.

Blake Aber · Predicate Ventures · 2026

The deal is the easy part

Signing a purchase agreement generates headlines. Capturing the value that justified the price generates returns. The gap between the two is acquisition integration, and it is where most deals succeed or fail.

The environment favors buyers who move. Global M&A activity in 2025 rose 40% in value to an estimated $4.9 trillion, putting it on track to be the second-highest year on record for deal activity (Bain). More deals means more integrations competing for the same management attention.

Speed is the strongest predictor

The single clearest signal in the research is timing. A deal is 2.6 times more likely to succeed, and delivers 40% more total returns to shareholders, when synergy targets are met within the first two years post-close rather than taking more than four (McKinsey).

Early momentum compounds. Companies that outperformed the market index over the life of a deal captured a run rate equal to 50 percent of their public synergy target in the first year alone (McKinsey).

The problem is that the runway before close keeps shrinking usable time. The median lag between signing and closing has stretched to about 6.4 months, a 25% increase over 20 years ago, and nearly one in six transactions now takes over a year to close (McKinsey).

That delay is not idle time. It is a window in which integration planning can happen—if the acquirer uses it well.

Plan before you can act

Antitrust and regulatory rules limit what two companies can share before close. Merging teams cannot pool commercial data or coordinate as one organization while the deal is pending.

The consequence of ignoring those limits is severe. The European Commission can fine companies up to 10% of revenue for gun-jumping, and it imposed that maximum on Illumina for closing its acquisition of Grail without approval (BCG).

Clean teams—separate groups of employees or third parties authorized to review sensitive information under legal protocols—let acquirers build detailed integration plans during the pre-close window without breaking the rules. When close finally arrives, the plan is ready to run rather than starting from scratch.

Protect the base business

Integration attention often flows to cost cutting and org charts. Meanwhile the acquired revenue quietly erodes.

Acquirers typically see sales decline eight percent in the quarter after announcing a deal (McKinsey). Customers hear about the change, competitors call them, and salespeople worry about their jobs. Left unmanaged, that dip becomes permanent.

Protecting existing revenue is the first job of integration. Retention plans for key accounts and salespeople, clear commercial ownership, and fast decisions on product overlap all matter before any synergy math pays off.

Synergies are bigger than the model

Most deals are priced against a synergy estimate built during due diligence. Treating that number as the ceiling leaves value on the table.

Looking for sources of value beyond what justified the deal—what McKinsey calls opening the aperture—can increase synergies by 30 to 150 percent above due-diligence estimates (McKinsey). The diligence model was built under time pressure with limited access. Once the two companies are combined, the real opportunities become visible.

Revenue synergies are the hardest to capture and the most sensitive to leadership. Between 70 and 80 percent of mergers that met or exceeded their revenue-synergy goals had strong senior-leadership involvement from the CEO down to sales (McKinsey). Cost synergies can be driven from a spreadsheet. Revenue synergies require executives to show up and set direction.

The case for doing this repeatedly

Integration skill is a muscle, and companies that use it often get stronger. The advantage of frequent acquirers is widening.

Bain found the gap in total shareholder returns between frequent acquirers and inactive companies was 130% between 2012 and 2022, up from 57% between 2000 and 2010 (Bain).

A disciplined, repeatable approach outperforms occasional large bets. The median excess return for companies using programmatic M&A was 2.1 percent over ten years, meaning they beat their peer groups by at least 20 percent in total shareholder return (McKinsey).

The reason is straightforward. Serial acquirers build integration into an operating capability—standard playbooks, dedicated teams, known metrics—rather than reinventing the process each time.

What a working integration looks like

The patterns in the research point to a short list of practices that separate deals that create value from those that erase it.

Start planning before close

Use the pre-close window and clean teams to build a plan that can execute on day one, without crossing regulatory lines.

Set a fast synergy timeline

Aim to hit synergy targets inside two years, and structure early wins in the first twelve months to build momentum and credibility.

Defend the revenue base

Assume an eight percent sales dip is the default outcome and build retention and communication plans to prevent it.

Put leaders on revenue synergies

Cost synergies can be delegated. Revenue synergies need visible, sustained involvement from senior leadership.

Look past the diligence model

Treat the deal thesis as a floor. Once combined, hunt for value the original model could not see.

The bottom line

Acquisition integration is not the administrative work that follows a deal. It is the phase where the price paid becomes either a return or a loss.

The data is consistent across sources: speed, protected revenue, engaged leadership, and repeatable discipline are what turn a signed agreement into a successful acquisition. Deals fail slowly, in the months after close, long after the announcement fades.

Building Agentic AI Systems: A Practical Guide

Blake Aber — Tue, 14 Jul 2026 15:18:23 +0000

Agentic systems earn their keep when they can plan, act, and recover without a human in every loop.

Blake Aber · Predicate Ventures

What an agentic system actually is

An agentic AI system is software that pursues a goal across multiple steps, choosing its own actions along the way. It differs from a single model call in one respect: it decides what to do next based on what it observed last.

That feedback loop is the whole game. A model that answers a question is a function. An agent that reads a ticket, queries a database, drafts a fix, and verifies the result is a process.

Most production agents share four parts: a planner that breaks work into steps, tools that let the model act on the world, memory that carries state across steps, and a control layer that decides when to stop.

Start with the task, not the framework

The common failure is picking an agent framework before defining the task. Frameworks encode assumptions about how much autonomy the model gets, and those assumptions often fight your problem.

Begin by writing down the task boundary. What inputs arrive, what output counts as done, and what actions are allowed. A support agent that can issue refunds is a different risk profile than one that only reads knowledge base articles.

Then ask how many steps the task takes. Single-step tasks rarely need an agent at all. A prompt with the right context will outperform a loop that adds latency and failure modes.

Reserve agentic designs for work that genuinely branches: where the right second action depends on the first result, and you cannot enumerate the paths in advance.

Tools are the interface to the world

A model without tools can only produce text. Tools convert intent into effect: a search API, a database query, a code executor, a payment call.

Design tools the way you design any API. Give each one a narrow purpose, a clear name, and strict input validation. A tool named update_record that accepts arbitrary SQL is a liability. A tool named set_order_status that accepts an order ID and one of three states is safe.

Return structured results the model can reason about. When a tool fails, say why in plain language the model can act on. "Order not found" lets the agent try a different lookup; a stack trace does not.

Keep the tool count small. Every additional tool widens the space of wrong choices. Models select tools more reliably from a list of six than from a list of sixty.

Memory and state

Agents need to remember what they have done. Without memory, a loop repeats itself or forgets a partial result.

Separate two kinds of memory. Working memory holds the current task: the plan, the steps taken, the observations returned. It lives for the duration of one run. Long-term memory holds facts that persist across runs: user preferences, past resolutions, learned constraints.

Do not stuff everything into the context window. Context is expensive and models degrade when it fills with stale detail. Store the full history externally and feed the model a summarized, relevant slice.

Retrieval matters here. When an agent needs a fact from long-term memory, fetch it by relevance rather than pasting the entire store. The quality of what you retrieve sets a ceiling on the quality of what the agent decides.

The control loop

Every agent runs a loop: observe, decide, act, repeat. The control layer governs that loop, and it is where most reliability comes from.

Set a step budget. An agent that can loop forever will, usually on the day you least expect it. Cap the number of iterations and the total token spend per run.

Define stopping conditions explicitly. The agent stops when it produces a valid final output, when it exhausts its budget, or when it hits an error it cannot handle. Ambiguity in the stop condition produces agents that spin.

Add verification before the final answer commits. A second check — a validator model, a schema test, a rule engine — catches the confident mistakes that a single pass misses.

Handling failure

Agents fail in ways single calls do not. A tool times out. A step returns unexpected data. The model picks a valid action for an invalid reason.

Plan for each. Wrap tool calls in retries with backoff for transient errors. Give the model a path to report that it cannot complete the task, so it stops instead of fabricating a result.

Log every step: the input, the chosen action, the observation, the decision. When an agent behaves oddly, the trace tells you which step went wrong. Debugging an agent without traces is guessing.

Set guardrails at the boundary, not inside the prompt. A prompt instruction not to delete data is a suggestion. A permission check in the tool that refuses the delete is a control.

Multi-agent versus single-agent

The instinct to split work across many specialized agents is strong and often premature. Each agent boundary adds a handoff, and handoffs lose information.

Use a single agent with several tools until you have evidence it cannot cope. One planner reasoning over one task is easier to debug than a committee passing messages.

Move to multiple agents when responsibilities are genuinely separate and the interface between them is narrow. A researcher agent that returns findings to a writer agent works when the contract between them is a clean document, not a running conversation.

Shipping and measuring

An agent that works in a demo and an agent that works in production are different systems. The gap is edge cases, and edge cases only appear at volume.

Build an evaluation set before you scale. Collect real tasks, define what a correct outcome looks like, and score runs against it. Track completion rate, step count, and cost per task.

Roll out behind a human check first. Let the agent propose actions while a person approves them. The approval data becomes your evaluation set and your evidence for when to remove the human.

The measure of an agentic system is not how impressive its reasoning looks. It is whether it finishes the task, at acceptable cost, more often than the alternative. Design for that number and the rest follows.

Agentic AI Systems: How They Work and Where They Fail

Blake Aber — Mon, 13 Jul 2026 18:18:24 +0000

Agentic AI systems act on goals instead of answering prompts—which is exactly why they are harder to trust.

Blake Aber · Predicate Ventures

What an agentic system actually is

Most AI tools respond. You send a prompt, they return text. The interaction ends there.

An agentic AI system does something different. It takes a goal, breaks it into steps, and executes those steps against real tools and data—often across multiple cycles without a human in between.

The distinction matters. A chatbot that drafts an email is a model. A system that reads your calendar, checks a customer record, writes the email, and sends it is an agent. The second one takes actions with consequences.

That shift from output to action is the entire reason the category exists, and the reason it carries risk.

The core loop

Every agentic system runs a version of the same loop: perceive, plan, act, observe, repeat.

The model perceives its current state, usually as text describing the task and available context. It plans a next step. It acts by calling a tool—a search, an API, a database query, a code execution. It observes the result. Then it decides whether the goal is met or another step is needed.

This loop is what separates agents from single-shot models. A single call cannot recover from a bad result. An agent can read the error, revise, and try again.

The quality of an agentic system depends less on the model and more on how tightly this loop is built. Loose loops wander. Tight loops finish.

The four components under the hood

Planning

The system needs a way to decompose a goal into steps. Some systems plan everything upfront. Others plan one step at a time and adjust as they learn. Step-by-step planning handles surprises better but costs more calls.

Tools

An agent is only as capable as the tools it can call. A system with access to search, a code interpreter, and a database can do real work. A system with none can only talk. Tool design—clear inputs, clear outputs, predictable errors—determines how often the agent succeeds.

Memory

Long tasks exceed what fits in a single context window. Agents use memory to carry state forward: what they have tried, what worked, what the user wants. Poor memory means the agent forgets its own progress and loops.

Control

Something has to decide when to stop. Without limits, an agent can spin indefinitely, burning tokens on a task it cannot complete. Step budgets, cost caps, and human checkpoints keep the loop bounded.

Where these systems break

Agentic AI fails in specific, repeatable ways. Knowing them is the difference between a demo and a deployment.

Compounding errors. Each step carries a chance of a mistake. Chain ten steps together and small error rates multiply. A system that is 95 percent reliable per step is roughly 60 percent reliable over ten steps. Long tasks amplify weakness.

Looping. An agent that cannot tell it is stuck will repeat the same failed action. Good systems detect repetition and change strategy or stop.

Tool misuse. The model may call the wrong tool, pass malformed arguments, or misread a result. Tools that fail loudly and clearly help the agent recover. Tools that fail silently poison the rest of the run.

Goal drift. Over many steps, an agent can lose sight of the original objective and optimize for a proxy instead. It completes something, just not the thing you asked for.

None of these are exotic. They show up in nearly every production system, and most engineering effort goes into containing them.

Why reliability, not intelligence, is the constraint

The models are already smart enough for many agentic tasks. The bottleneck is consistency.

A task that succeeds 70 percent of the time is unusable for anything with real stakes. A human still has to check the output, which erases the time saved. The value of an agent comes from trusting it to finish without supervision, and trust requires reliability that most systems do not yet reach.

This is why the strongest agentic deployments are narrow. A system scoped to one workflow—processing a specific document type, handling a defined support category, running a fixed data pipeline—can be tested, measured, and hardened until it clears the reliability bar. Broad, open-ended agents rarely do.

Narrow scope is not a limitation to apologize for. It is the current path to systems that actually work.

How to evaluate an agentic system

When assessing a system, ignore the demo and ask about failure.

Measure completion rate on real tasks, not curated examples. Track how often a human has to intervene. Watch the cost per completed task, since agents that loop are expensive as well as unreliable.

Check what happens when a tool returns an error or an unexpected result. A system that handles the unhappy path well is closer to production than one that only shines when everything goes right.

Ask where the human sits. The best current designs keep a person at the checkpoints that carry irreversible consequences—sending money, deleting records, contacting customers—while letting the agent run freely on low-risk steps.

What this means for building

The teams shipping useful agentic systems share a pattern. They pick a task narrow enough to measure. They build tools with clear contracts. They instrument the loop so they can see where it fails. They set hard limits on steps and cost. And they keep humans on the decisions that matter.

The teams that struggle chase generality. They want one agent that handles anything, and they get a system that handles nothing reliably.

Agentic AI is a real capability, not a marketing category. It works when the loop is tight, the scope is defined, and the failure modes are managed. It fails when any of those are ignored.

The technology will improve. The discipline required to deploy it will not change. Build narrow, measure honestly, and treat reliability as the product.

Commercial Due Diligence: A Buyer's Field Guide

Blake Aber — Mon, 13 Jul 2026 18:18:23 +0000

Commercial due diligence tests whether the story behind a deal survives contact with the market it depends on.

Blake Aber · Predicate Ventures

What Commercial Due Diligence Actually Answers

Financial due diligence tells you whether the numbers are real. Commercial due diligence tells you whether they will still be real in five years.

The distinction matters. A clean audit confirms historical performance. It says nothing about whether the market that produced those results is growing, shrinking, or about to be reshaped by a competitor the seller failed to mention.

Commercial due diligence examines the demand side of a business. It asks who buys, why they buy, whether they will keep buying, and what could make them stop.

The output is a judgment on the investment thesis. Either the market supports the return you underwrote, or it does not.

The Four Questions Behind Every Assessment

Most commercial due diligence work reduces to four questions.

How big is the market, and where is it going? Total addressable market matters less than the direction and rate of change. A large market in decline is worse than a small market compounding at twenty percent a year.

Where does the target sit within it? Market share is a starting point. The harder question is whether that share reflects a durable advantage or a temporary lead that competitors can erase.

How loyal are the customers? Revenue that renews without effort is worth more than revenue that must be re-won every year. Retention, concentration, and switching costs define the difference.

What could break the thesis? Every deal has a small number of assumptions that carry most of the risk. The job is to find them and test them.

Sizing the Market Without Fooling Yourself

Seller-provided market figures deserve suspicion. They are usually built to support the price.

A sound market estimate works from the bottom up. Count the customers who could plausibly buy, estimate what they spend, and reconcile that against top-down industry data. When the two approaches disagree by a wide margin, the gap itself is a finding.

Growth rate matters more than absolute size for most investors. A market growing faster than the broader economy gives a business room to expand without taking share from rivals. A flat market forces every gain to come from someone else, which invites price competition.

Segment the market before trusting any aggregate number. A company may operate in a large category while serving a niche that behaves nothing like the whole.

Reading Competitive Position

Competitive position is where optimistic theses tend to fail.

Start with the structure of the market. A few large players with high margins signals barriers to entry. A crowded field with thin margins signals commoditization, regardless of what the pitch deck claims.

Then locate the target inside that structure. Ask what the business does that competitors cannot easily copy. If the answer is "nothing specific," the margins are borrowed and will be reclaimed.

Pricing power is the clearest evidence of position. A company that can raise prices without losing volume holds real advantage. One that discounts to keep customers is defending, not leading.

Watch for competitors that do not yet show up in the seller's framing. Adjacent players, new entrants, and substitute products often pose more threat than the direct rivals everyone tracks.

Customer Evidence Beats Management Narrative

Management will describe a business as they wish it to be seen. Customers describe it as it is.

Customer interviews are the most useful part of commercial due diligence and the most often shortchanged. A structured set of conversations reveals why customers chose the target, what would make them leave, and how they rate alternatives.

The patterns matter more than any single quote. When several customers independently cite the same weakness, that weakness is real. When praise is vague and complaints are specific, treat the complaints as the signal.

Revenue concentration deserves direct attention. If a handful of accounts drive most of the revenue, the health of those relationships determines the outcome of the deal. One departing customer can invalidate the entire model.

Retention data completes the picture. Cohort analysis shows whether customers stay and expand or churn and shrink. Reported retention that management cannot reproduce from raw data is a warning.

Stress-Testing the Thesis

The purpose of the work is not to produce a report. It is to decide whether the price makes sense.

Good commercial due diligence isolates the two or three assumptions that carry the return. Perhaps the thesis requires a certain growth rate, a specific retention level, or the success of a new product line. Name those assumptions and test each one against evidence.

Build the downside explicitly. If growth comes in at half the plan, does the deal still work? If the largest customer leaves, how much of the equity is exposed? A thesis that only functions under favorable conditions is a bet, not an investment.

Separate what the analysis found from what it could not verify. Honest reporting of the unknowns is more valuable than false confidence. Buyers can price uncertainty; they cannot price hidden assumptions.

Timing and Scope

Commercial due diligence usually runs alongside financial and legal workstreams, on a compressed schedule. Two to six weeks is typical, depending on deal size and access.

Scope should follow the thesis. A roll-up in a fragmented market needs deep competitive mapping. A subscription business needs granular retention analysis. Spending equal effort on every question wastes the limited time available.

Access shapes what is possible. Sellers control the flow of information, and the most revealing data often arrives late. Building customer contact into the process early prevents a scramble at the end.

What Good Work Produces

The deliverable is a clear position on the deal, supported by evidence a skeptical partner can check.

It should state whether the market supports the thesis, where the target stands against competitors, how durable the revenue is, and which assumptions carry the most risk. It should also say what remained unknown and why.

The test of quality is simple. Six months after close, does the business behave the way the analysis predicted? Work that survives that comparison earns its cost many times over.

Commercial due diligence does not remove risk from a transaction. It replaces vague optimism with a priced set of bets, which is the most any buyer can ask before writing the check.

Private Equity CEO Predicts AI Will Reshape Deals

Blake Aber — Mon, 06 Jul 2026 10:42:32 +0000

When a private equity CEO predicts AI will change the business, the useful question is which parts, and on what timeline.

Blake Aber · Predicate Ventures

The prediction, stated plainly

A private equity CEO predicts AI will move from a marketing line into the core of how firms operate. The claim is not that software replaces investors. It is that the work of sourcing, diligence, and portfolio management gets faster and cheaper per unit of output.

That framing matters. Predictions about AI often collapse into two camps: everything changes, or nothing does. The more grounded view sits between them, and it maps to specific tasks rather than whole job functions.

Where the change lands first

The earliest effects show up in tasks that are repetitive, text-heavy, and already well-documented. Private equity has plenty of these.

Deal screening is one. Firms review far more targets than they buy, and most of the early filtering is reading. Financial summaries, market notes, and management materials all pass through analysts before anyone commits real time. Models that read and rank these documents shorten the first pass.

Diligence is another. Contract review, customer concentration checks, and comparison against precedent deals are structured enough for machines to draft first and humans to verify. The output is a starting document, not a final call.

What stays human

Judgment about people, incentives, and timing does not automate well. Whether a management team executes under pressure, whether a market holds, whether a price reflects real risk. These decisions rest on reading situations that resist clean data.

The prediction assumes AI handles the reading and drafting while partners keep the decisions. That division holds only if firms treat model output as a draft to challenge, not an answer to accept.

Portfolio operations, not just deal-making

The more durable claim concerns portfolio companies after the deal closes. This is where a private equity CEO predicts AI will produce measurable returns.

Many portfolio companies run functions that AI touches directly. Customer support, sales operations, finance close cycles, and marketing content all carry labor cost that models reduce. A firm that owns dozens of companies can apply the same playbook across all of them.

That repetition is the point. A single company adopting AI captures a local gain. A private equity firm rolling the same approach across a portfolio captures the gain many times, and it can measure results across a controlled set of businesses.

The margin math

Private equity returns depend on buying a business, improving its operations, and selling at a higher multiple or higher earnings. AI enters on the operations side by lowering cost or raising output without proportional hiring.

If a portfolio company cuts service cost while holding quality, margin improves. Improved margin supports a higher exit price. The prediction reduces to a claim that AI adoption becomes a standard lever in the operational improvement toolkit, sitting alongside pricing changes and procurement.

The risk in the prediction

Every adoption story carries a cost story, and this one has three.

The first is measurement. Firms that count AI savings before checking quality tend to reverse course. A support system that closes tickets faster but leaves customers unhappy trades a visible metric for an invisible loss. Honest measurement requires tracking outcomes the model does not optimize for.

The second is integration cost. Dropping a model into an existing workflow rarely works on the first attempt. Data has to be cleaned, staff has to be trained, and processes have to be rebuilt around the new tool. The savings arrive after the investment, not before.

The third is uniformity risk. When many firms apply similar AI playbooks, the operational advantage narrows. If every buyer can raise margins the same way, the improvement gets priced into acquisition multiples, and the excess return fades. Early movers gain; the field catches up.

Reading a CEO's prediction critically

When a private equity CEO predicts AI will drive returns, the statement serves two audiences at once. Limited partners hear a firm that stays current. Portfolio managers hear a directive to adopt.

Both readings are reasonable, and both can be true while the specifics stay vague. The useful test is whether the prediction attaches to measurable claims: which functions, what cost reduction, over what period, verified how.

Predictions without those attachments are positioning. Predictions with them are operating plans. The distinction tells you whether a firm has done the work or is describing an intention.

Questions worth asking

An investor or operator evaluating such a prediction can push on a few points.

Which portfolio companies have adopted AI, and what did results look like against a baseline. How does the firm separate AI-driven gains from other operational changes. What did integration cost, and how long until payback. What quality metrics guard against savings that hide losses.

Answers to these reveal whether the prediction rests on evidence or enthusiasm.

What this means for the sector

The direction of the prediction is likely correct. AI reduces the cost of document-heavy and repetitive work, and private equity contains a lot of both. Adoption spreads because the economics favor it.

The timeline and magnitude are the open questions. Task-level gains arrive quickly and are easy to demonstrate. Portfolio-wide, verified return improvement takes longer and depends on execution that varies widely between firms.

The firms that gain most will treat AI as an operational discipline with measurement attached, not a theme to announce. They will track quality alongside cost, invest in the unglamorous integration work, and accept that the advantage erodes as competitors adopt the same tools.

A private equity CEO predicts AI will change the business. The prediction holds. What separates the firms that benefit from the ones that merely talk about it is the willingness to measure, and the honesty to report what the numbers actually show.

Specs, not prompts: from harness engineering to hive mind

Blake Aber — Thu, 02 Jul 2026 14:48:16 +0000

Spec-driven AI orchestration is the architecture that compounds at portfolio scale, not prompt engineering. The infrastructure shift parallels Terraform for infrastructure, declarative CI/CD, and Kubernetes for containers.

Blake Aber · Predicate Ventures · 2026

What is harness engineering

Anthropic's engineering team recently published work on infrastructure for long-running AI applications. Their claim: "the infrastructure around the model matters as much as the model itself."

They call this discipline harness engineering. It covers context management, tool integration, verification loops, and resilience patterns. The key insight: two products using identical LLMs can produce vastly different outcomes depending on their supporting architecture.

Their research identified production challenges:

Context limitations. Naive compression loses important information. Work with Claude Sonnet 4.5 revealed performance degradation with accumulated compacted context, requiring full resets to restore quality.
Over-ambition in agents. Without structured decomposition, models attempt complex tasks in single attempts. Outputs appear complete but aren't.
Unreliable self-evaluation. Agents confidently praise mediocre work. External verification (what Anthropic calls the generator-evaluator pattern) is necessary.

These solutions work for single agents and humans. Multi-agent scenarios (five agents with different tools and shared budgets) compound the coordination overhead nonlinearly.

The infrastructure gap

Shipped agent systems demonstrate that LLMs can write code, analyze data, and draft documents. But teams rebuild scaffolding constantly. Each new workflow requires re-engineering context flow, output verification, and budget enforcement. Knowledge from previous projects doesn't transfer.

Verification becomes human-intensive. Teams handle five workflows daily through manual review. Fifty workflows daily? The system breaks.

Context costs compound exponentially in multi-agent chains. Forwarding Agent A's complete output through Agents B and C, where information silently truncates at limits, represents standard practice in most frameworks today.

Eighteen months of prompt engineering results

Industry teams achieved real systems through careful prompt design, retrieval-augmented context, and chain-of-thought decomposition. But a ceiling exists.

Output distributions resist narrowing like test suites do. Verification requires human re-reading. Without external evaluation, quality remains aspirational. Context becomes hidden cost. Redundant information flows through agent chains while critical details get truncated.

The harness couples tightly to specific workflows. Changing verification strategies or budgets requires complete rewrites, not reconfiguration. This is precisely what Anthropic identifies as problematic: teams build bespoke harnesses repeatedly.

The specification as coordination mechanism

If harness engineering is the discipline, specifications function as the executable contract.

What if multi-agent systems accepted specifications instead of prompts? If you're unsure which side of that line your own AI work sits on, the spec-versus-prompt founder's diagnostic is a quick way to check. Not rigid schemas requiring engineering expertise to write, but structured contracts generated from plain English defining:

Deliverables: with types (code, documents, APIs, infrastructure)
Verification: acceptance criteria with priorities and methods (test runners, LLM judges, or combinations)
Agent assignments: capability matching, concurrency limits, retry budgets
Cost controls: hard limits on tokens, USD, wall-clock time, concurrent agents

Generated from natural language and reviewed before execution, specs become machine-readable contracts that orchestrators execute against. The pattern mirrors Terraform's plan-before-apply workflow.

Three structural changes

Context becomes structured rather than concatenated

Agents receive task descriptions, acceptance criteria, typed outputs from upstream dependencies (artifacts, not full transcripts), and feedback from prior attempts if retrying.

Context assembly is priority-ordered and budget-aware. Under pressure, low-priority sections drop first. Task descriptions and acceptance criteria remain intact. Agents receive less but more relevant context, reducing token usage while improving quality.

Verification integrates into contracts

Verification becomes mandatory and composable at every task graph node. Each deliverable has acceptance criteria with specified verification methods:

Test verification
LLM judge evaluation with structured feedback
Chained verification with short-circuit failure modes

When verification fails, the system stores expectations versus results and judge suggestions. That structured feedback injects into retries: not generic "try again" prompts but specific improvement guidance.

Orchestration becomes declarative

Coordination logic (ordering, dependencies, dispatch, failure handling) lives in application code under prompt-based systems. Spec-driven systems generate task graphs from specifications. The planner handles decomposition. Dependency graphs manage ordering. Budget trackers enforce limits. Circuit breakers prevent cascading failures.

This pattern mirrors successful infrastructure shifts: Terraform for infrastructure declaration, declarative CI/CD pipelines, and Kubernetes for container orchestration.

Economic impact

Multi-agent orchestration costs escalate with naive context handling. Five-task sequential chains consume 3–4x tokens of actual useful generation.

Spec-driven context changes the economics:

Priority-ordered assembly delivers only necessary information
Typed dependency outputs forward artifacts rather than generation transcripts
Budget-aware truncation drops lower-priority content first
Cache-friendly consistent spec prefixes improve prompt caching hit rates

A nine-task workflow across four agents operates for under $1, not because models are cheap, but because context remains efficient.

Cost visibility matters equally. Per-agent and per-model token tracking enables actionable insights like identifying that test-engineer agents consume 40% of budgets while producing 20% of deliverables.

Multimodal provider support

Rooben is the open-source spec-driven orchestrator I maintain (github.com/blakeaber/rooben). It is the working reference implementation for the architecture described above.

Most AI tools hardwire to single vendors, trapping workflows in ecosystems. Rooben implements an LLMProvider protocol: minimal interfaces any backend implements. Current support includes Anthropic, OpenAI, AWS Bedrock, and Ollama for local models, each with built-in cost tracking.

Mix providers within single workflows: Claude for planning, GPT-4o for code generation, local models for sensitive operations. StateBackend protocols work similarly, defaulting to local JSON while supporting S3, databases, or custom backends.

When model capabilities shift, as they inevitably will, swap one configuration line. Specs transfer. Verification criteria transfer. Learning history transfers. Investments compound regardless of current leading models.

Practical implementation

The command rooben go "Build a REST API with CRUD endpoints, input validation, tests, and a Dockerfile" generates a specification for review and approval.

Execution proceeds through:

Specification decomposition into task graphs
Structure validation (no cycles, orphaned tasks, missing dependencies)
Parallel task dispatch to agents
Structured context delivery (only necessary information)
Output verification via test runners and LLM judges
Structured feedback injection for failed task retries
Cost reporting showing per-agent, per-model token usage

The system stays protocol-based throughout: swappable LLM providers, state backends, verifiers, planners, and agents via structural typing without framework lock-in or inheritance requirements.

Future architecture

Current open-source capabilities handle flat fan-out: planners spawn 3–5 agents working task graphs in parallel.

Next phases ship in Rooben Pro, the commercial extension currently on a waitlist. Via the A2A (Agent-to-Agent) protocol in Rooben Pro, agents spawn sub-agents. A research lead receives tasks, writes sub-specifications, dispatches specialized workers, verifies output, and reports upward. Agent trees, rather than flat pools.

Specs compose naturally: parent spec deliverables become child spec inputs. Organizational layers in Rooben Pro map team members to departments and roles with tracked outcomes across workflows, enabling the system to learn contextual definitions of quality.

The gradient progresses from individual developers using the CLI for single workflows to armies of specialized agents mapped to organizational roles, each refining specifications over iterations. The 50th workflow execution measurably improves over the first.

Moving forward

Rooben remains open-source with a public roadmap covering expanded agent transports, cross-run learning, marketplace integrations, and hierarchical orchestration. Detailed technical comparisons and harness engineering guidance are in the project documentation.

A 30-Day Engagement: Federal Compliance Workflow Automation

Blake Aber — Thu, 02 Jul 2026 14:47:36 +0000

A sanitized case writeup of a single-operator AI engagement that shipped three deliverables in one week.

Blake Aber · Predicate Ventures · 2026

This is one example of what 30-day shippable AI looks like in practice. The client was a federal-compliance-adjacent software company. Names and specifics are sanitized. The shape of the work is what matters.

The situation

The company had a compliance-decisioning workflow that sat at the heart of their product: when a customer submitted an inquiry, a compliance team had to review the inquiry against a structured set of regulations and produce a decision with supporting evidence. The work was high-stakes (regulatory exposure if wrong), high-volume (hundreds of inquiries per week), and human-bottlenecked (each inquiry took an analyst 30-60 minutes to review). The team was small. The backlog was growing.

The CEO had been pitched a 6-month "AI transformation" engagement by an enterprise consultancy. The price was a six-figure monthly retainer with a 12-month minimum. The timeline didn't match the urgency, the price didn't match the headcount, and the scope didn't match what was actually broken.

What they needed was someone who could pick the right narrow piece, ship something useful in a defined window, and not require a 90-day discovery phase first.

The engagement

One operator (me), four working weeks. Total scope: three concrete AI-enabled deliverables that took the analyst's role from "spend 45 minutes per inquiry" to "spend 10 minutes per inquiry, with the rest done by AI and reviewed by the human." The arithmetic: a 4x throughput improvement on the bottleneck workflow, with audit-grade traceability preserved for regulatory review.

The four weeks broke down roughly as follows. Week 1: scoping, decision-record on what gets built and what gets cut, mapping the existing compliance workflow against the AI's capability and limits. Week 2: ship the classification-and-retrieval engine that maps inquiries to relevant regulatory evidence. Week 3: ship the deterministic decision layer that produces a recommended decision with full audit trail. Week 4: ship the analyst-facing interface that surfaces the AI's output with the supporting evidence in one place, ready for the analyst's 10-minute review.

What got shipped

Three artifacts. All three live in production.

Deliverable 1: classification-and-retrieval engine. The engine takes a customer inquiry, identifies the relevant regulatory framework, and pulls the specific evidence artifacts that bear on the decision. It presents them to the AI decisioning layer as structured context. The analyst used to do all of this by hand: opening regulatory PDFs, searching for the right paragraphs, copy-pasting evidence into a working document. The engine compresses 20-30 minutes of pre-decision work into seconds.

Deliverable 2: deterministic decision layer. Given the inquiry plus the retrieved evidence, the decision layer produces a recommended decision with full traceability. The output records what evidence was considered, which regulatory clause was applied, what the recommendation is, and a confidence signal indicating how clear-cut the case is. The decision layer is not an LLM that "thinks about it." It's a structured harness that combines models (where they fit), rules (where they fit), and evidence retrieval (where the question is fundamentally a documentation question). The output is auditable end-to-end.

Deliverable 3: analyst-facing review interface. The analyst sees the AI's recommended decision, its full evidence trail, and its confidence signal in one screen. The job shifts from researcher-and-decider to reviewer-and-validator. The 45-minute task compresses to a 10-minute task. The audit log captures both the AI's recommendation and the analyst's final call.

Each deliverable shipped in roughly one calendar week. None of the three required a six-month engagement, a discovery phase, or an enterprise platform purchase.

What it cost

Roughly the cost of one month of a senior contract-engineer's time. Not enterprise-engagement money. Not vendor-software-license money. A specific scope, a specific timeline, a specific price. If it hadn't worked in 30 days, the client would have paid for one month of a senior person and owned the artifacts produced. They could have hired someone else to extend the work, shelved it, or run with what existed.

The client didn't shelve it. The deliverables are still in production. The team has continued the work in-house from there.

What this engagement is not

It is not a "transformation." It didn't replace the analyst team. It didn't restructure the company's operating model. It didn't require a procurement cycle, a steering committee, or a press release. It was three workflow improvements scoped narrowly enough to ship in a month, against a workflow chosen specifically because it scored cleanly on the 30-day shippable criteria (one named workflow, 5+ hours/week of named-analyst time, repeatable shape, measurable output, human-in-the-loop review).

The engagement model is what enterprise AI gets wrong about small-and-mid-sized businesses. You don't need a transformation. You need someone to pick the right narrow piece and ship it. The same logic drives the cheap, fast AI wins available to owner-operated businesses: the constraint isn't budget, it's choosing a workflow narrow enough to finish.

What worked, what didn't

What worked: scoping discipline. The single biggest reason 30-day engagements fail is that scope creeps in week 2. Holding the line on "three deliverables, defined at week 1, shipped one per week" was the difference between landing in 30 days and landing in 90.

What didn't work as cleanly: the original Week 1 scope had four deliverables. The fourth was a customer-facing self-service portal that would have let customers triage their own inquiries before submitting. We cut it at end of Week 1 because building it would have required UI design work that wasn't in scope, plus a customer-data-handling layer that needed dedicated security review. The right call was to ship the three deliverables and propose the fourth as a separate engagement. The client agreed. The portal became a follow-on conversation that happened on its own merits.

Why this matters for your business

If you have a workflow that scores cleanly on the 30-Day Shippable AI Scorecard, the engagement model that worked for the federal-compliance company can work for you. The pattern is industry-agnostic. It has run for me at Fortune-500 healthcare scale (CVS Aetna/Signify integration), at growth-stage marketplace scale (Whop fraud detection and content integrity), and at single-operator federal-compliance scale (this engagement). The same scoping discipline applies. The same pricing model applies. The same 30-day envelope applies.

The hard part is picking the right workflow. The 30-Day Shippable AI Scorecard helps with that. The engagement that follows is the easy part.

Spec vs. Prompt: A Founder's Diagnostic

Blake Aber — Thu, 02 Jul 2026 14:46:55 +0000

Most founders assume that when the AI output is wrong, a better prompt will fix it. Sometimes it does. More often, the problem is upstream: the system doesn't know what it's supposed to produce. Prompting harder moves the problem around without solving it.

Answer each question honestly. Score 0 if yes, 1 if no or unsure. Add them up at the end.

The five questions

1. Can you write down in one paragraph — without referencing the AI — exactly what the output should look like?

What does it contain? What doesn't it contain? What format? What does "good" look like versus "bad"? If you find yourself wanting to describe what the AI does rather than what the output is, score 1. This is the same gap that lets beta users tell you the product works while the people who left could have named exactly what was missing.

2. If the AI received perfect input, would you know within 30 seconds whether the output was right or wrong?

Not whether it was great — whether it was correct. If evaluation requires judgment you haven't defined anywhere, score 1.

3. When you change the prompt, does the problem disappear — or does it move?

"Fixed" one failure mode, exposed a different one? The problem moved. Score 1.

4. Can you describe specifically how the AI fails when it's wrong — not just "it's wrong," but the pattern of wrongness?

"It's wrong in the same way on inputs that have X characteristic" is a failure mode. "Every failure feels different" is not. If you can't name the pattern, score 1.

5. Does the AI know what it's not supposed to produce?

Has the system been designed for out-of-scope inputs, ambiguous requests, and edge cases — or does it always produce something, even when it shouldn't? If it always produces, score 1.

Scoring

0–1: Prompt problem. The spec is clear. Iterate on phrasing, examples, or model selection.

2–3: Probably a spec problem. You've asked for approximately the right thing, but not precisely enough. Write the spec first, then return to prompting.

4–5: Spec problem. You haven't defined the output well enough for a human to produce it reliably — so the AI can't either. Write the spec: what the output contains, how to evaluate whether it's correct, what to do on edge cases. Then come back to the AI.

The agentic products that compound over time are built on specifications, not prompts. Specs are testable, revisable, and shareable. Prompts are ephemeral. If you scored 3 or higher: write the spec first.

Governance-as-Design

Blake Aber — Thu, 02 Jul 2026 14:46:15 +0000

Eval, audit, and rollback as design inputs for clinical-adjacent AI. Not review-stage checkboxes.

Blake Aber · Predicate Ventures · 2026

Most enterprise AI programs treat governance as a retrofit. Build the model. Ship the demo. Hand it to compliance for review. Compliance flags the issues that should have been designed in. Engineering re-scopes. Timeline slips. The pilot looks impressive in the steering-committee deck and never makes it to production.

The programs that actually ship at health-payer scale do not work this way. The same discipline shows up in how healthcare AI ships around the enterprise blocker cycle: scope is decided before anything is built. They treat governance as a design input, co-authored with compliance and clinical risk from day 1, not handed off at month nine. The eval harness, the audit boundary, the rollback surface, and the clinician-facing confidence signal are scoped before the model is selected. They shape what gets built. They are not artifacts produced after.

This is the distinction that decides whether a program ships.

The four primitives

Eval harness. Not the test set. The standing infrastructure that runs the model against named scenarios continuously, tracks output drift over time, and flags when the distribution of inputs has shifted enough that the validation set no longer covers production reality. The eval harness is what turns "did the model pass at week zero" into "is the model still passing." Designed in: dashboards, alerting, ownership. Designed out: silent failure.

Audit boundary. Not the audit log. The decision about which decisions, at what granularity, with what retention, are recorded and traceable. The boundary is where the system commits to "this output, with this evidence, was produced under these conditions." Most programs draw the audit boundary too narrow (model-in / model-out, no upstream context) or too wide (every keystroke, no signal). The audit boundary that lets a clinician defend a decision under regulatory review is a deliberate scoping call, not a logging-volume question.

Rollback surface. Not the model-version manifest. The operational mechanism that takes a deployed model out of production within a defined window (minutes, not weeks) when something is going wrong. Rollback surface includes the human authority (who can pull the model), the technical mechanism (how the model is pulled), the fallback path (what happens to in-flight requests), and the post-rollback audit (what's reconstructed from the audit boundary). Most programs treat rollback as something they'll figure out if needed. The programs that ship treat rollback as the first thing they design.

Clinician-facing confidence signal. Not the confidence score. The decision about how the model communicates its uncertainty to the clinician, in language and at a granularity that lets the clinician calibrate when to override. A 0.87 confidence number is useless. A signal that says "this output is in a region where the model has historically had a 12% override rate at your institution" is calibration. Confidence signaling is where most clinical-adjacent AI quietly fails. The model may be 90% accurate, but if the signal trains the clinician to trust it on the 10% where it fails, deployment is worse than no model at all.

What "co-authored from day 1" actually looks like

Co-authored from day 1 doesn't mean compliance attends the kickoff. It means the eval-harness ownership, the audit-boundary scope, the rollback authority, and the confidence-signal vocabulary are decided before the model is selected. The model is selected partly on which models can satisfy those four primitives, not just on raw accuracy.

In practice, this looks like a four-way decision-record signed at week one:

The eval harness owner is named (a specific person, not "the platform team")
The audit boundary is scoped (specific decision granularity, retention period, evidence schema)
The rollback path is authored (named authority, named mechanism, named fallback)
The confidence-signal vocabulary is sketched (what the clinician sees, not the raw probability)

The decision-record exists before any model is procured. It is signed by AI, compliance, clinical leadership, and engineering. It is updated when load-bearing decisions change. The decision-record is the artifact that distinguishes design-input governance from review-end governance.

Three signs your program is design-input, not review-end

Compliance can answer "what would a rollback look like?" without consulting engineering. If compliance has to ask, rollback is engineering-owned, which means it's review-end.
Clinical leadership has approved the confidence-signal vocabulary, not the confidence-score format. If clinical leadership signed off on "we'll surface a 0-1 confidence value," that's signal-as-checkbox. Calibration is a vocabulary question, not a numeric-range question.
The eval harness is running against last quarter's input distribution, not last year's validation set. If the harness hasn't been updated since model selection, it's not a harness. It's a snapshot.

Programs failing all three are review-end. Programs passing all three have the design-input discipline that ships clinical-adjacent AI at scale.

Why this matters now

Two pressures are converging. Regulatory: the AI-governance posture that was sufficient for cloud-era enterprise software is not sufficient for clinical-adjacent AI. Auditors are starting to ask design-input questions, not review-end questions. Programs without design-input artifacts are going to discover this expensively. Operational: as model capability plateaus and converges across vendors, the structural advantage in health-payer-scale AI shifts to the orgs with the harness, audit, and rollback discipline to deploy any model safely. The parallel in regulated legal work is the AI governance infrastructure that policy alone can't catch, where the prevention lives in the pipeline, not the policy document. The differentiator stops being which model and starts being which infrastructure.

The retrofit programs build impressive demos. The design-input programs build production systems. The difference is not which models you select. It is what you decide before the models are selected, and who owns each decision when reality changes.

5 AI Wins Under $10K for Owner-Operated Businesses

Blake Aber — Thu, 02 Jul 2026 14:45:34 +0000

What 30-day shippable AI actually looks like in practice. Five examples from businesses like yours.

Blake Aber · Predicate Ventures · 2026

People hear "AI" and picture a six-figure pilot with a steering committee and an 18-month timeline. Here's what it actually looks like when an owner picks the right workflow and ships something real. If you want to see the same idea play out at a larger scale, the 30-day federal compliance workflow case study walks through one start to finish.

1. Invoice follow-up: general contractor, ~25 employees

The office manager spent 6-7 hours every Monday chasing unpaid invoices: checking which were overdue, drafting follow-up emails, sending them, logging responses. An email automation tool now does the repetitive part. It checks the invoice spreadsheet each Monday, drafts follow-ups for anything past 30 days, and queues them for a 20-minute review. She reads through, clicks send on what looks right, and edits anything that needs a human touch.

Cost: ~$300/month in tooling; ~$1,200 one-time setup. Year-one under $5,000.
Time saved: 5-6 hours/week returned to the office manager.
Why it was shippable: same-shape output every time (invoice follow-ups are structurally identical), and a human reviews before anything goes out.

2. Estimate generation: landscaping company, ~15 employees

After every new-client call, the owner spent 30-45 minutes converting handwritten notes into a formatted estimate. An AI drafting assistant now takes a five-sentence post-call summary and generates the estimate draft. The owner reviews, adjusts the 20% that requires real judgment, and sends.

Cost: ~$150/month. Year-one under $2,000.
Time saved: 3-4 hours/week, redirected to client relationships.
Why it was shippable: consistent format (same fields every estimate), and the owner is comfortable reviewing before sending.

3. Appointment confirmation: specialty medical practice, ~12 staff

Front desk spent 2-3 hours every morning calling to confirm next-day appointments, leaving voicemails, handling callbacks. An automated text sequence now confirms 48 hours out, logs replies, and flags reschedule requests for the front desk to handle. Staff now manage exceptions, not routine confirmations.

Cost: ~$200/month.
Time saved: 3-4 hours/week of front-desk time.
Why it was shippable: identical workflow for every patient. Confirmed vs. flagged output is easy to verify. A human handles anything out of the ordinary.

4. Vendor quote follow-up: property management firm, ~8 staff

A property manager was chasing 15-20 contractor quotes per month by hand: initial request, manual follow-up at 3 days, another follow-up at 5 days, logging who had responded. An email automation sequence now handles the initial request and follow-ups. The manager reviews responses in her inbox, not a queue of who still needs a nudge.

Cost: ~$300/month. Year-one under $4,000.
Time saved: 3 hours/week.
Why it was shippable: one named person owned the workflow, the email structure was consistent, and the outcome was easy to measure (quote received or not).

5. Lease renewal document prep: residential property management, ~50 units

Sixty to ninety days before each lease expiration, the property manager had to send renewal notices, track responses, and prep the paperwork. An automated reminder sequence handles the outreach. An AI drafting tool pre-populates the renewal document from a spreadsheet of tenant and unit details. The manager reviews every document before it goes out.

Cost: one-time ~$2,500 build.
Time saved: 5-6 hours/month at 50 units. Doubles at 100.
Why it was shippable: identical structure per renewal, and the manager reviews before anything is sent.

Every one of these started with the same question: which workflow is eating a named person's week, and is it the same shape every time with a verifiable output? The 30-Day Shippable AI Scorecard turns that question into five quick tests you can score yourself.

The 30-Day Shippable Scorecard is the 10-minute version of that question.

If your workflow passes, we'll know in a single call whether it's a 30-day fit. If it doesn't pass, you'll know what's missing before you spend a dollar on AI.

An Agentic-Product Research Teardown

Blake Aber — Thu, 02 Jul 2026 14:44:54 +0000

What synthetic user research revealed that real-user research couldn't, and what the product team should have done differently.

Blake Aber · Predicate Ventures · 2026

The product I'm going to describe doesn't exist under that name. It's a fictionalized composite. Close enough to be useful, sanitized enough to protect everyone involved. The methodology is real. The finding was real.

The product

Call it Flowkit: an agentic task-management tool for small creative teams. The core promise: you describe a project in plain language, and Flowkit breaks it into tasks, assigns owners, and tracks progress without you touching a spreadsheet. The founding team had built a technically impressive prototype. Demos were strong. Waitlist was healthy.

The problem showed up six weeks post-launch. Most users who completed onboarding didn't come back. Not because the product was broken. It worked. They just didn't return.

Why real-user research couldn't diagnose it

The team ran standard user interviews. They talked to a dozen people who had onboarded. The feedback was uniformly positive: "Really powerful," "Love the vision," "Will definitely use it more once I have a bigger project." The team heard this and concluded the timing was off. Users didn't have the right project yet. They decided to wait.

This is the trap. The users they interviewed were the users who stayed. The users who left didn't take Calendlys. They just stopped. Real-user research structurally excludes the leakers (the 70% who abandoned before reaching the moment of value) because those people are no longer reachable through in-product recruitment. It's the same blind spot that makes your beta users lie to you: the sample you can reach is the sample least likely to tell you what's broken.

The synthetic persona that surfaced the signal

Using the Voice-of-Agents methodology, I built behavioral archetypes from public signals: forum posts, app-store reviews of competing tools, support threads, and Reddit discussions where people described why they stopped using task-management software. I wasn't looking at Flowkit users. I was looking at behavioral patterns that predicted abandonment in this category.

One archetype emerged clearly: the Efficiency-Seeker.

The Efficiency-Seeker adopts tools quickly but abandons them just as quickly when the time cost of setup exceeds the perceived time savings of the output. They evaluate tools in the first session. If they don't see value in the first 10 minutes, they close the tab and don't return. They do not give tools "another chance."

When I ran this archetype against Flowkit's onboarding flow, the failure point was obvious: step 3.

Step 3 asked users to describe their first project in plain language. The intent was to let the agentic system generate the initial task breakdown. But the text field was blank. No placeholder. No example. No scaffolding. The Efficiency-Seeker, confronted with a blank text box asking for a "project description," froze. They didn't know what level of detail to provide. They tried two or three phrasings, got results that felt off, and closed the tab.

The product team had designed step 3 for the user they wanted: the one who was excited to explore the system's capabilities. They hadn't designed it for the user who would arrive in a hurry, already skeptical, looking for a reason to stay.

The specific product change implied

Replace the blank text field at step 3 with a structured template: three fields (project name, team members, first deadline) that pre-populate a project description the system can work with. Give users a "use this as-is" button so the Efficiency-Seeker can skip past the description stage entirely and get to the task breakdown immediately.

The Efficiency-Seeker doesn't want to craft the perfect description. They want to see whether the output is useful. Getting them to the output is the job of step 3, not asking them to formulate the input. The blank field also pushed the burden of specification onto the user — and as the spec-versus-prompt diagnostic makes clear, an underspecified input is the thing most likely to produce output that feels off.

The founding team shipped this change. Onboarding completion rate improved materially in the first two weeks.

What this means for your cohort founders

The founders in your program are running user interviews on the people who stayed. Those are not the users who will determine whether the product has PMF. The users who matter most (the ones who left before completing onboarding) are invisible to conventional user research because they're gone.

Synthetic personas built from behavioral archetypes let you hear from those users before the real-world abandonment happens. You can simulate the Efficiency-Seeker's experience in 30 minutes, for under $2 in model costs, before you've built the product. Or after launch, when conventional research has already failed to explain your churn.

The methodology isn't a replacement for talking to real users. It's what fills the gap when real users can't, or won't, tell you why they left.

DEV Community: Blake Aber

Post Acquisition Integration: A Field Guide

The gap between the deal and the return

Why integration difficulty has risen

Start integration before close

The first 100 days

People decisions come first

Protect the revenue

Set a small number of priorities

Systems and data

Measuring whether integration worked

What separates good buyers

Related reading

Acquisition Integration: What Drives Deal Value

The deal is the easy part

Speed is the strongest predictor

Plan before you can act

Protect the base business

Synergies are bigger than the model

The case for doing this repeatedly

What a working integration looks like

Start planning before close

Set a fast synergy timeline

Defend the revenue base

Put leaders on revenue synergies

Look past the diligence model

The bottom line

Building Agentic AI Systems: A Practical Guide

What an agentic system actually is

Start with the task, not the framework

Tools are the interface to the world

Memory and state

The control loop

Handling failure

Multi-agent versus single-agent

Shipping and measuring

Related reading

Agentic AI Systems: How They Work and Where They Fail

What an agentic system actually is

The core loop

The four components under the hood

Planning

Tools

Memory

Control

Where these systems break

Why reliability, not intelligence, is the constraint

How to evaluate an agentic system

What this means for building

Related reading

Commercial Due Diligence: A Buyer's Field Guide

What Commercial Due Diligence Actually Answers

The Four Questions Behind Every Assessment

Sizing the Market Without Fooling Yourself

Reading Competitive Position

Customer Evidence Beats Management Narrative

Stress-Testing the Thesis

Timing and Scope

What Good Work Produces

Related reading

Private Equity CEO Predicts AI Will Reshape Deals

The prediction, stated plainly

Where the change lands first

What stays human

Portfolio operations, not just deal-making

The margin math

The risk in the prediction

Reading a CEO's prediction critically

Questions worth asking

What this means for the sector

Related reading

Specs, not prompts: from harness engineering to hive mind

What is harness engineering

The infrastructure gap

Eighteen months of prompt engineering results

The specification as coordination mechanism

Three structural changes

Context becomes structured rather than concatenated

Verification integrates into contracts

Orchestration becomes declarative