Replaying an Old Assignment Through an Agents Lens
A few years into my career at Axiom, I was handed an assignment that seemed simple on the surface: put together a newsletter.
The context mattered. We were a nascent contracts data business operating inside a larger alternative legal services firm. Our business — turning contracts into structured data for M&A due diligence and integration — was maybe ten percent of the company’s revenue. The other ninety percent ran a different model entirely: placing attorneys with in-house legal departments on a consulting basis. That larger business was our best source of referrals. When one of their senior account executives recognized that a client’s problem was better suited to what we did, they’d send it our way — and they’d still get credit toward their goals, so incentives were aligned.
The head of our business wanted to double down on that referral engine. His solution was internal marketing — get the other teams excited about what we were building, make them feel connected to it, make them more likely to think of us when the right client situation came up. He tasked me, roughly a year and a half into the job, with making that happen through a newsletter compiling the latest cross-functional updates.
I’ve been thinking about that assignment lately because it’s a useful test case for something that comes up constantly: where do agents actually fit into knowledge work, and where does the person still have to drive?
What the Assignment Actually Involved
Before getting into the AI question, it’s worth being specific about what the work required, step by step.
The first thing I had to do was understand the business problem behind the assignment. The newsletter wasn’t the goal — increasing sales revenue was, through increased origination from the referral channel. That distinction mattered because it shaped every subsequent decision about what to include and how to frame it.
The second thing was figuring out what to compile. I started with our CRM to pull sales history, stakeholder context, deal status, and anything useful I could surface without taking up anyone’s time. Then I reached out across sales, product, marketing, and client service for anything the CRM didn’t capture — their read on what was worth highlighting, recent wins, delivery milestones, collateral. This produced a pile of good raw material: deals closed, new clients landed, product updates shipped, branding work completed.
The third thing — and this is where most of the judgment lived — was deciding what actually mattered and why, and how to communicate that to our audience.
Winning a deal with a new enterprise client was significant not just for its revenue, but for what it signaled about our ability to win that class of business and what it meant for the senior person on the other side of the house who originated it. A major renewal and upsell was worth highlighting not just as a financial outcome but as a recognition of the delivery team whose work made it possible. The connections between how collaboration across different parts of the business enabled our sales motions — and giving specific credit to the people involved — that’s what made the newsletter land, not the facts themselves.
Finally, the fourth thing was packaging it into a format that salespeople, executives, and other business stakeholders would actually read, let alone enjoy and be inspired by.
Running It Back With Agents
The interesting question isn’t whether an agent could do this today. Parts of it clearly could be addressed. The interesting question is which parts, and what that leaves for the person.
Compilation is largely addressable. The mechanical work of gathering updates across departments — if that information lives in a shared system with appropriate access — is exactly the kind of multi-step retrieval task agents handle well. Connect to the CRM, pull recent updates by department, surface them in a structured format. That’s real and useful. In my case I was doing much of this manually through CRM data research, email and conversations. Some of that friction goes away.
That said, the compilation step has its own constraints worth naming. The relevant information isn’t always well-structured or correctly tagged. Ambiguity in underlying data produces ambiguous outputs. And there are legitimate access and privacy boundaries — not every relevant conversation is logged, not every system is connected, and not every organization should want them to be. These aren’t temporary engineering problems. They’re features of how organizations actually function.
Summarization is addressable, and honestly it was already addressable before agents. Given a set of inputs, an LLM produces coherent summaries. This isn’t a new capability agents unlock — it’s baseline LLM behavior. Useful to have in the workflow, not a step-change.
Formatting and packaging is partially addressable. A first draft of the newsletter structure, given clear inputs and a well-defined template, is something an LLM handles comfortably. The blank page problem gets easier. The judgment in the final version is still a human job.
What doesn’t move, at least not yet: the judgment calls at the beginning and middle of the process.
Understanding why the assignment existed — that the real goal was referral activation, not newsletter production — required knowing the business, the person making the ask, and the organizational dynamics well enough to read between the lines. That context wasn’t written down anywhere. It came from being embedded in the organization.
Deciding what actually mattered in a pile of raw updates required knowing which outcomes were genuinely significant versus routine, which relationships between teams were worth reinforcing, and what would actually resonate with a specific audience of attorneys and senior salespeople being asked to care about something adjacent to their primary work. An agent surfacing everything equally would have produced a longer document, not a better one.
A More Recent Illustration
There’s a more current version of the same dynamic that I’ve been thinking about while using Claude Code for my own projects.
When Claude Code runs, it periodically pauses and asks whether you want to auto-accept its next actions or review them manually. It’s a small UX detail, but it captures something important: the model itself doesn’t know when human review is warranted. It can execute well across a wide range of tasks. What it can’t do is determine, in your specific context with your specific constraints, which outputs are safe to accept without review and which ones need your eyes on them first.
That decision — when to trust the output and when to verify — is a judgment call. And it’s not incidental that the tool surfaces it explicitly as a user choice rather than resolving it internally. The people who built it understand that this is a structurally human decision, not a capability gap to be closed in the next model release.
The newsletter assignment had the same structure. An agent could have helped me compile, draft, and format. What it couldn’t have done is tell me which deal was worth leading with, or how to frame a delivery team’s contribution in a way that would actually motivate a sales floor to send us more referrals. Those calls required context that lived in relationships and organizational dynamics that no system was tracking.
What This Suggests Practically
The newsletter assignment was never going to be fully automated, and that’s not a failure condition. The right way to think about it is as a workflow with a natural division of labor: the person drives the judgment-heavy front end, the tools handle the execution-heavy middle, and the person reviews and refines the back end.
In practice that looks something like this. You identify the business problem clearly enough that it can guide downstream decisions — human work. You use the tools to pull and structure relevant inputs from the systems that have them — agent territory. You evaluate what came back against the judgment you brought in at the start — human again. You use the tools to draft and format — mixed, depending on how clearly you’ve defined what good looks like. You review and refine with your audience in mind — human, and not optional.
The thing I’d push back on is the framing that treats this division as temporary — that eventually the agent handles the judgment calls too as models improve. Maybe. But the judgment calls in the newsletter assignment depended on context that is structurally difficult to provide to any system, not just ones with current capability limits. The organizational dynamics, relationship histories, and political considerations that informed my decisions weren’t in any system. Getting them there fully would require a level of organizational surveillance that most environments wouldn’t and shouldn’t accept.
Until that changes, the person isn’t a bottleneck to be engineered around. They’re the thing that makes the output worth producing in the first place.