If you listen to Acquired, you've probably heard them repeat the Bezos advice: do the stuff that makes your beer taste better. His point was: spend your time on what creates actual product value, and outsource everything else.
I'm struck by how many enterprises caught up in token-maxing (i.e., treating the number of AI tokens consumed as a measure of success in and of itself) seem determined to do everything except make their beer taste better.
For credit investors, their “beer” is the investment judgment, negotiating experience, or experimental knowledge that belongs to the firm. A credit firm should spend its effort improving that judgment and experience, with infrastructure that preserves the results and makes them useful again. Tokens spent re-reading the same files and reconstructing earlier decisions do not make the beer taste any better.
But that still leaves the question: which AI tools belong in which parts of the work? Consider a race car driver. Peak performance on a circuit is their profession, but they still need to buy groceries. They take their Civic to do that because navigating a crowded grocery store parking lot in a race car is a great way to ruin an otherwise perfectly ordinary Tuesday.
Later, at home on a couch considerably more comfortable than anything their engineers can afford, the driver might review lap times or investigate whether a setup change contributed to the tenth of a second gain that paid for said couch. The driver needs the team’s telemetry and analytical tools, but can leave the race car in the garage. Back at the track, they need the car and crew that helped pay for that couch.
In this analogy, the Civic is the general-purpose LLM, the race car is the specialist execution environment, and the telemetry is the record of actions taken. I use general-purpose AI throughout my own day, and I work at F2, where we build software for credit investment teams.
I think the specialist should own the authoritative record and execution environment for its domain, while making both accessible from the general assistant. That is a stronger obligation than producing a good answer when someone uploads a file.
The telemetry has to exist first
Suppose our driver asks the analyst, “How have we adjusted camber at this track on rainy days, and what happened to our times through turn six?”
The analyst hesitates, “Right. So, funny story. We wrote down the camber settings, but we didn’t write down whether it was raining.” An awkward omission for a team whose office has no roof.
They might get lucky with an external weather archive and reconstruct enough to make a useful comparison. Someone else thought to record the weather, which is generous of them and slightly embarrassing for the racing team.
Now ask how their tire pressures or engine temperatures affected performance later in the race. If the team never logged those readings, a public weather report will be of limited assistance. You’re SOL, however enthusiastically the assistant offers to “dig deeper.”
Buying a database gives the team somewhere to put the readings, but someone still has to know which ones to capture and how to connect them to the car, setup and lap. That is the responsibility I would place with the specialist system: preserve the evidence and its meaning while the work happens, including the details nobody has yet thought to ask about.
Benchling makes this case in scientific work, describing a connected record of experimental plans, execution, results and subsequent decisions (Benchling).
A folder of final documents is an incomplete memory
The same issue appears in legal work. Imagine reviewing a contract and wanting to understand the negotiating positions your company has accepted before.
Reading every historical contract from beginning to end would be an expensive way to answer a question about one provision. I would want to identify the comparable agreements, find the relevant clause wherever it appears, understand how it differs from our standard and see which exceptions were approved.
The system needs a structured view of the contracts: parties, dates, status, clause types, amendments and relationships to the underlying source. If the reason for an exception matters, that reasoning needs to have been captured too.
I would preserve the original artifact and each subsequent version as immutable evidence, alongside an indexed, queryable representation of their contents. Extracted fields and summaries should point back to the exact source and remain correctable; they should help an agent identify what deserves close reading without becoming an uncheckable substitute for the contract.
An agent reviewing a liability provision should be able to narrow the precedent set to comparable agreements with materially different caps or exceptions, then inspect those clauses in context. Maintaining that index makes the next review start from an informed shortlist.
Foundation Capital describes a related gap in its work on “context graphs”: business systems often record the outcome while losing the exceptions, approvals and precedents that explain how it was reached. Its argument is that systems participating in execution can preserve those decision records as the work happens (Foundation Capital).
This is why I think the specialist should own the domain’s system of record. The original files might remain in SharePoint and the structured data in an existing database, but the specialist should govern their meaning, relationships, revisions and approved state, while making that knowledge available to other agents.
Golub Capital already had databases when it chose F2. Our partnership is intended to embed the firm's proprietary knowledge, experience and investment judgment into the systems supporting its investment work (F2 and Golub Capital).
The challenge is making that knowledge usable by expert agents: knowing what to retrieve, when it matters, which derived analysis needs updating and how the team arrived at the final work product. A final memo should remain connected to the assumptions, revisions and decisions that produced it.
Credit investing requires long workflows
A fast lap is one achievement. Running a race requires the team to carry information forward as conditions change, decide when to stop, respond to what the car is doing, and understand how an earlier decision affects the options available now.
Now imagine getting a new pit engineer every lap. He has access to the team's files, but no idea how the race has gone, which tires you tried, or why you changed the setup.
“Great job completing that lap! How are you feeling about your driving today? Would you like me to help you think through a tire strategy?”
He then reaches for a tire that makes no sense for the conditions. By lap three, the driver would probably want to hit him over the head with a wrench, then change the tire himself. Anyone who has reopened an AI project and spent the first ten minutes explaining the work back to an enthusiastic assistant will recognize the feeling.
Even within specialist professions, much of the work is short. Summarizing a borrower or producing an initial screener may be a bounded task that a general assistant handles well. In our earlier example, that’s the grocery trip, and a Civic is fine for it.
But producing a screener is only one part of investing in a deal. The investment process continues through diligence, modeling, memo preparation, structuring and committee review, with earlier conclusions changing as new evidence arrives.
Suppose diligence reveals that a borrower's largest customer can terminate sooner than expected. The analyst changes the revenue assumptions, which weakens the downside case and raises a question about debt capacity. The memo now needs to explain the exposure and propose protections.
The committee asks for a tighter structure. That sends the team back to the model and into another negotiation, after which a reviewer needs to check whether the agreed terms address the original concern. Each artifact builds on the last one, and some changes have to travel back through work that appeared finished.
I think of that whole chain as long work, even if it consists of many short agent runs across several applications and people. A vendor should have to show that it can carry the investment case through that chain before claiming it can do the job. Five impressive document demos do not tell me what happens when the assumptions change halfway through.
In that setting, I want the system to know which assumptions changed, which outputs depend on them and which conclusions now need review. I want a colleague to pick up the work without re-uploading the same data room and reconstructing the reasoning from a conversation they were not part of.
This is where I expect a well-built specialist platform to earn the largest advantage. It can encode the relationships between the artifacts and maintain them as work proceeds, giving each person and agent a reliable starting point for the next step.
Anthropic encountered a similar problem in long-running coding work: agents struggled across sessions even with context compaction. Its solution included structured requirements, progress records and version history so each session could continue from a known state (Anthropic). McKinsey makes the organizational argument too, identifying the verification, reconciliation and routing between workflow steps as a major opportunity beyond improving each step individually (McKinsey).
Long work changes the economics
A short demonstration hides much of this. Upload a document, ask a question and get an impressive answer, and the cost and effort look manageable.
At F2, our internal token-cost modeling puts roughly two-thirds of consumption in a poorly structured generalist workflow into context accumulation, agent and tool overhead, retries and verification. A substantial token budget can be consumed repeatedly preparing the system to work.
Extend that interaction across a whole transaction and the architecture matters more. If each stage retrieves the same files, extracts the same facts and reconstructs earlier decisions, the bill includes repeated preparation as well as new analysis. Additional agents and reviewers can duplicate that work further.
Those tokens carry a cost, even when caching discounts repeated input. Production work also generates analysis, revisions and finished artifacts, making the mix of reading and writing important to the bill (Anthropic’s pricing explanation).
A specialist agent backed by a structured knowledge layer can move preparation out of the repeated loop. It can extract and index documents at ingestion, retain validated results, track changes and retrieve the relevant passages or values for the next step.
That work still costs money, and the indexes need maintenance as records change. A reusable representation lets preparation serve many questions, agents and colleagues, with new work focused on what has changed.
Anthropic documents the same engineering principle in its work on MCP: discover tools when needed, filter results before they enter the model’s context and execute suitable operations in code (Anthropic engineering). The opportunity is to reduce repeated preparation while preserving the verification that consequential work requires.
The specialist should understand the recurring work well enough to decide what to prepare, how to structure it, and which checks belong at each step. I would evaluate that advantage across the whole job, including integration, review and rework. If the specialist cannot demonstrate an advantage there, it has not earned another line in the software budget.
Edgar on our team deserves the credit for the token-economics work behind this analysis. I'm borrowing a small slice of a subject he understands much better than I do. I suspect he'll have plenty more to say about it soon, possibly beginning with corrections to this section.
Use the general assistant without abandoning the specialist
I want to ask my general assistant for a briefing based on specialist records, delegate a bounded analysis to specialist tools, or move into the working environment needed to inspect and finish the job. The handoff should preserve the work already done.
Harvey describes precisely this kind of progression: legal questions and Vault access within Copilot, a “View in Harvey” option for deeper analysis, and continued drafting and redlining in Word (Harvey). Burges Salmon describes its adoption strategy similarly, with a firm-wide Copilot foundation complemented by Harvey for matter-specific legal workflows (Burges Salmon).
Benchling also explains that when an external assistant uses its MCP connector, the request invokes Benchling’s specialist agents behind the scenes (Benchling). That is the combination I want: the freedom to work in a general assistant while drawing on a specialist’s structured context and execution. The user should not have to reconstruct the lab’s history to make that possible.
The specialist interface may also appear inside the assistant through mechanisms such as MCP Apps (MCP Apps). Changing tabs is less consequential than preserving the record, controls and context.
I want the Civic for the grocery trip, access to the telemetry from home and the right car and team at the circuit. When the race starts, I want us building on everything we learned in practice, with each decision informing the next. Oh and I want that fancy couch, too.
