How Lake Forest Private Equity Firms Can Use the Claude Agent SDK to Build Their Own Deal Team

Lake Forest, Ill. , April 21, 2026. The CIM lands in the partner's inbox at 8:47 PM on a Tuesday. It is the seventh one this week. The intermediary's note is friendly and short: process this Friday, our seller is fielding three other groups, indications by next Wednesday. The partner has a quarterly meeting in the morning, two portfolio company calls after lunch, and a Booth panel in Hyde Park on Thursday evening. The CIM is 84 pages. The financial model is a 17-tab Excel file. The brief is, on its face, a fit. It is also the third "fit" this month that will receive a polite pass because nobody at the firm has the bandwidth to underwrite it properly.

This is, for most lower-middle-market PE firms in the Lake Forest, Illinois area, the actual binding constraint. Capital is not the problem. LP demand is not the problem. The problem is that a two- or three-partner shop running $150M of committed capital can look at maybe 200 deals a year with any seriousness. The market produces somewhere between 800 and 1,500 sourceable deals in their size range. Most of what gets passed on is not a no, it is a not-this-week.

The traditional fix is headcount. Add an associate. Add another. Build a deal team. And then, three years later, fundraise on a bigger fund just to cover the comp load. Many funds in the $50M to $300M AUM range never make that jump because the unit economics do not work.

What changed in the last six months, and especially with the version of the Claude Agent SDK that shipped this week, is that the analyst-level work product can be produced by software running on a partner's laptop, billed at API-token prices, without anyone at the firm writing a line of production code. Anthropic's engineering team described the design principle bluntly: "give your agents a computer, allowing them to work like humans do."

What follows is the architecture of three specific builds that a Lake Forest PE firm could stand up in a quarter, what the new SDK release actually changed, and where this approach still needs a human.

What Actually Shipped in the Claude Agent SDK

The Claude Agent SDK is not a product a partner buys off a website. It is a Python and TypeScript library, published by Anthropic, that wraps the same agent loop powering Claude Code. A developer writes a few dozen lines of code and gets, in exchange, an agent that can read files, run shell commands, search the web, call APIs, and reason across a long workflow without anyone in the loop. The SDK is the supplied infrastructure. The firm supplies the workflow definition, the data, and the guardrails.

The current release, v0.2.110 on the Python side, with a matching TypeScript package on npm, added four pieces that matter for a finance-team build.

A get_context_usage() method on ClaudeSDKClient. This is the unglamorous one. The method lets a running agent query, at any point, how much of its context window has been consumed and by which categories: tool definitions, conversation history, system prompts. For an overnight deal-screening run, it is the difference between an agent that quietly burns through a 1M-token budget on housekeeping and an agent that knows when to compact its own state. A finance team running unattended workloads needs that telemetry the way a portfolio manager needs a margin call alert.

typing.Annotated for per-parameter descriptions. The @tool decorator and the create_sdk_mcp_server helper now accept Python's Annotated type to attach plain-English descriptions to each parameter of a custom tool. In practice, that means the firm's controller, who writes a Python function called fetch_portfolio_company_pl(company_id, month), can annotate company_id with "Bace identifier of the portfolio company, e.g. PT-014" and have that description show up in the JSON schema the model sees. Less guessing. Cleaner tool calls. Fewer fix-it loops.

Periodic AI-generated progress summaries for sub-agents. The new agentProgressSummaries option (or agent_progress_summaries in Python) tells the SDK to ask the model, on a cadence, for a one-paragraph summary of what each running sub-agent is doing. For a multi-agent diligence pass with five sub-agents working in parallel on different sections of a data room, this is the difference between a black box and a status console. The partner can glance at the summaries from a phone in the carpool line at Lake Forest Country Day School and know whether to let the run continue.

Custom session_id support. The firm can now assign its own session identifiers when it starts an agent run. That sounds like plumbing. It is. It is also what allows the firm's CRM, deal-tracking spreadsheet, or internal Notion workspace to thread an agent run back to a specific deal record without storing Anthropic-generated UUIDs in two places. The version-control implication is that every CIM that comes in gets one durable identifier shared by the email, the deal record, the agent run, and the eventual IC memo.

Two earlier capabilities, both of which had quietly stabilized over the last two quarters, also matter for the PE use case. The 1M-token context window, available on Sonnet 4.5 with the context-1m-2025-08-07 beta header and now standard on Sonnet 4.6 and Opus 4.6, lets a single agent load an entire mid-market data room in one pass. And sub-agent support, which became reliable in the 0.1.60 release, is what makes a five-document-types-in-parallel diligence pass possible without writing an orchestrator from scratch.

Pricing is the part that makes the math work for a small firm. Sonnet 4.5, the working model for most agent loops, runs $3 per million input tokens and $15 per million output tokens, per Anthropic's published pricing. A 200-page CIM and full data room is, very generously, a 500,000-token input. A complete underwriting memo with cited sources is, again generously, a 30,000-token output. The model spend on one full diligence pass, end to end, is roughly $1.95 in input plus $0.45 in output. Call it $3 of token spend per deal. The fully loaded cost of a junior associate doing the same first-pass work is closer to $300.

Why This Matters Specifically for a Lower-Middle-Market PE Firm

Lake Forest is not Wilmette and is not Greenwich. The PE firms here are mostly second- and third-fund operators who left larger Chicago shops to run their own book. The geography matters: an LP base that skews heavily to North Shore family offices, Booth and Kellogg alumni networks, and Northern Trust private wealth clients expects the partner they wrote a check to to actually be on the deal. There is no junior team layer to hide behind.

The economic shape of a $150M fund, two-partner shop is roughly this. A 2% management fee on $150M produces $3M of fee revenue per year. After office, audit, legal, fund admin, two partner draws, an IR person, and a controller, there is realistically room for one associate. Maybe two if the partners take less. Hiring the associate raises the cost-per-deal-screened in a way that improves the firm's coverage of the market only marginally, because the associate also has to do portfolio support, IC prep, LP reporting, and the rest of the analyst-level work the partners have decided not to do themselves.

The build described below is not a replacement for that associate. It is a way for the firm to operate as if it had three or four of them on the screening side, while still hiring the one good senior associate who actually closes deals and works on portfolio.

Three workflows illustrate the point.

Use Case 1: An Inbound Deal Screener That Reads Every CIM Overnight

The shop's actual sourcing constraint is reading speed, not deal flow. The screener attacks reading speed.

The first build is the simplest, the cheapest, and usually the one that pays for the whole project in the first quarter. A daily agent run, scheduled for 4 AM Central, that ingests every email received the prior day at the firm's deals@ mailbox, parses any attached CIMs, broker books, or teaser pages, scores each opportunity against the firm's stated investment thesis, and emails the partners a one-page ranked digest by 6:30 AM.

The infrastructure is small enough to fit on a single page. A Python script using claude_agent_sdk, scheduled by cron on a $20-a-month Lightsail box, with read-only access to the firm's Gmail or Outlook via OAuth and write access to a single Notion database where ranked opportunities land. The agent uses the SDK's built-in Read, Bash, and WebFetch tools, plus one custom tool the controller writes to query the firm's existing pipeline database to deduplicate against deals the firm has already passed on.

What v0.2.110 specifically enables here is the session_id option. The firm assigns each daily run an ID like screener-2026-04-21, which threads through the agent's logs, the Notion records it creates, and the email digest it sends. When a partner six weeks later asks "why did we pass on the Wisconsin tooling deal in late April," the partner's CRM lookup returns the exact agent transcript that produced the pass recommendation. There is no missing institutional memory.

The economic case is straightforward. At a typical inbound volume of 250 emails a week with an average of 35 actual opportunities embedded, the agent processes roughly 140 deals a month. At an average input of 60,000 tokens per CIM and 4,000 tokens of output per scored entry, the monthly model spend is approximately $33 of input plus $8 of output, plus a few dollars of WebFetch usage when the agent looks up public information about a target. Call it $50 a month. The firm's screening throughput, measured as deals seriously evaluated per partner-week, roughly triples.

The rate-limiting factor is no longer reading. It is whether the partners want to take the meeting on the deals the agent ranks 8 or higher.

Use Case 2: Per-Portfolio-Company Agents That Watch Monthly P&L for Drift

Covenant breaches are almost always visible in the trailing six months of management financials. The hard part is having someone read every package every month.

The second build is structurally different. Instead of one screening agent running daily across all inbound, the firm stands up one persistent monitoring agent per portfolio company. Each agent owns a session ID like portco-acme-tooling and is invoked monthly when the portfolio company submits its standard reporting package: a P&L, a balance sheet, a covenant compliance certificate, and a one-page CEO commentary.

The agent compares the new package to the prior twelve months of submissions, the original LBO model the firm built at acquisition, and the loan agreement covenants. It produces a structured output: green / yellow / red on each covenant, a variance explanation for any P&L line item that moved more than 10% versus plan, a flag on any non-recurring item the CEO commentary attributes to "timing," and a one-paragraph summary in the firm's voice for the monthly portfolio review meeting.

The technical reason this build is now responsible to run unattended is the new get_context_usage() method. Each portfolio agent is loading, on every monthly run, the prior year of financials plus the original model plus the loan documents. That is comfortably 500,000 to 700,000 tokens of inputs alone, before the new month's package is added. With 1M context on Sonnet 4.5 or 4.6, there is room. Without the ability to query consumed context mid-run, an agent could quietly hit the ceiling and silently truncate. The new method lets the firm wrap each run in a hook that pages the partner if context utilization on any portfolio agent crosses 85%.

The typing.Annotated support also matters here, in a subtle way. The custom tool the firm writes to fetch the loan covenant definitions takes parameters like covenant_type, test_period, and cushion_threshold. With Annotated descriptions, the model sees, for each parameter, the firm's own definition of what each field means, which is materially different from what those terms mean in a generic credit agreement. A leverage covenant defined as "Senior Funded Debt to TTM Adjusted EBITDA, calculated quarterly on a four-quarter rolling basis, with permitted add-backs limited to 12.5% of EBITDA" cannot be inferred from the parameter name alone. The annotation closes that gap.

For a firm with 9 portfolio companies, the model spend on monthly monitoring runs to roughly $80 a month. The output replaces, for the first-pass review, what a junior associate would do over a long Saturday at the office. The partner spends Friday morning on the three companies the agents flagged yellow or red, not on the six that came in clean.

Use Case 3: A Multi-Agent Diligence Pass That Drafts the IC Memo

A clean data room is not a clean IC memo. The work in between is exactly the work a junior diligence team does.

The third build is the most ambitious of the three and the one that most directly substitutes for traditional analyst headcount. When a deal that came through the screener moves to LOI and the data room opens, the firm spawns a diligence orchestrator: a parent agent that coordinates five specialist sub-agents working in parallel.

The five sub-agents, each defined as an AgentDefinition with its own focused system prompt and a scoped tool set, divide the data room as follows. A financials sub-agent handles the QofE binder, audited statements, monthly P&Ls, and AR aging. A customer sub-agent handles concentration analysis, contract terms, churn data, and any reference call notes. An employee sub-agent handles the org chart, compensation schedules, key-person identification, and equity arrangements. A legal sub-agent handles material contracts, litigation, IP, and the corporate book. A market sub-agent does external research using WebSearch, builds a competitive map, and pulls public comps.

The orchestrator's job, in this design, is to route documents to the appropriate sub-agent, keep track of open questions, and assemble the final memo from the five contributions. The 1M-token context window on Sonnet 4.5 is what makes the orchestrator viable as a single coordinator rather than a handoff queue. The orchestrator can hold the full inventory of every document in the data room, every sub-agent's running notes, and the firm's IC memo template all at once.

This is the build where agentProgressSummaries earns its keep. With five sub-agents running in parallel for several hours, the partner needs to know which ones are stuck, which ones have flagged something material, and which ones are simply still grinding. The summaries arrive in a Slack channel the partner can check from anywhere.

The output is not a finished IC memo. It is a credible first draft, fully cited, with the boring parts populated and the partner's actual judgment work surfaced cleanly. A senior associate or partner spends an afternoon, not three weeks, finishing it. For a firm doing six platform diligence passes a year and twelve add-on diligence passes, the time savings on this single workflow is the equivalent of close to one full associate's headcount.

Token spend on a full diligence pass with five sub-agents running on Sonnet 4.5 is, by published rates, in the $20 to $80 range depending on data room size. The boutique transaction advisory firm that would otherwise be hired for the same first-pass work bills somewhere between $25,000 and $75,000.

How to Get Started in the First Quarter

Standing up the three builds at once is the wrong move. The right sequence, based on what tends to actually finish at small firms, is one workflow at a time over a single quarter. The order below is the one that returns capital fastest and builds the operating muscle for the next two.

What This Approach Does Not Replace

A blunt note, since it goes wrong regularly when firms get excited about the savings.

The Claude Agent SDK does not replace the senior associate who actually structures deals, negotiates with lenders, sits in the management meetings, and does the relationship work with intermediaries. It does not replace the partner's judgment on which yellow flag is a real yellow flag and which one is the controller having a bad month. It does not replace the LP-facing work, the fundraising work, or the board work at portfolio companies.

What it replaces is the analyst-level, well-defined, structurally repetitive work that exists in every PE firm and that small firms typically choose not to staff because the headcount cost cannot be justified at sub-$300M AUM. The screener replaces the analyst who would read 200 CIMs a month. The portfolio monitoring agent replaces the associate who would read 9 reporting packages on a Saturday. The diligence orchestrator replaces the analyst who would spend the first ten days of every diligence period building summary tables.

The error to avoid is treating the agents as a substitute for hiring at all. The firms that get value out of this build are the ones that use the freed-up partner time to do more partner-level work: more management meetings, more LP visits, more conviction time on the deals that matter. The firms that try to use the agents to "run leaner" without also reallocating the freed time tend to end up exactly where they started, with slightly cheaper screening and no meaningful change in outcomes.

There is also a security and confidentiality discipline this build requires. Data rooms contain non-public, often legally restricted, material. The right path for a PE firm is to use the Claude API directly with the firm's own data-handling agreement, or to deploy through Amazon Bedrock or Google Vertex with the firm's existing enterprise contracts. Anthropic's API does not train on customer data. Free consumer tiers of any AI tool are not the right place for a CIM or a covenant package.

A Final Note on Timing

The Claude Agent SDK has been technically capable of most of what is described above for the better part of six months. What changed in the v0.2.110 release is the operational telemetry: context-usage queries, custom session IDs, sub-agent progress summaries, and clean per-parameter tool descriptions. Those are not flashy features. They are the difference between an agent build that a partner will actually run unattended overnight and one that requires babysitting.

The window in which deploying this produces a sourcing or diligence-speed edge over the next firm down Western Avenue is, optimistically, the next three to four quarters. By the time the broader market catches up, every serious lower-middle-market shop will have some version of this stack running. The firms that move now compound the gains for the rest of the fund cycle.

For partners who want to think through the right starting workflow for a specific firm, or want a second set of eyes on how to structure the rollout so it actually sticks rather than ending up as another half-built internal tool, a free 30-minute AI audit is available. In person at a Lake Forest coffee shop or on video. No obligation, no pitch deck. The output is a one-page plan.

The technology shipped. The question is which workflow a firm decides to ship first.

Frequently Asked Questions