When agents do the entry-level work, where does your team’s context live?

A lot of what a software team knows has never been written down. Why the export leaves a cell blank, what a customer actually wanted, which option the team tried and dropped. It’s in the heads of the people who were there, and it gets passed on to new people mostly by asking. A new engineer asks why something works the way it does, sits in on a review, and hears the reasoning behind the decisions that were made.

Agents change that in two ways. They can take over some of the work that early-career people used to do, so a team with more agents may end up hiring fewer people at entry level. And agents don’t eavesdrop. A coding agent wasn’t in the planning meeting. It starts each task from what’s written down: the work item, the code, the instruction files in the repo, and whatever else it’s pointed at.

The context that used to pass from person to person has to be written where both people and agents can find it. That means on the work itself, alongside the requirement and the code, not in a wiki nobody opens. A decision made in a meeting and recorded nowhere else is a decision your agents won’t see.

This is not an argument for or against hiring fewer junior people. That’s a decision for each team. The written record also helps the juniors you do hire. A new engineer who can read why a decision went the way it did doesn’t have to know who to ask.

Context moves through people

The best evidence for this is older than coding agents. In a 2007 field study of 17 developers at Microsoft, researchers from Carnegie Mellon University and Microsoft Research found that coworkers were the most frequent source of information. The questions developers most often had to put off were about design and program behavior, “such as why code was written a particular way.” In most cases, design knowledge “was only in coworkers’ minds,” and developers often had to defer tasks because “the only source of knowledge was unavailable coworkers.” Read Ko et al. on information needs in software teams. That’s one company and a small sample, and not all of the developers were new hires. It still matches what most engineering leaders see: the reason behind a decision usually sits with a person.

Agents work from a different source. Anthropic’s own documentation for Claude Code says: “Each Claude Code session begins with a fresh context window.” What carries over from session to session is mainly what’s in files such as the project’s CLAUDE.md, which the team shares through version control. See the Claude Code documentation on how it remembers a project. That’s one vendor’s tool, but the general principle applies. An agent knows what it can read.

Here’s the part that is our reasoning rather than a research finding. The fewer people who join at entry level, the fewer people ask the questions that make the context explicit. The senior engineer who used to walk each new hire through the export’s quirks does it less and less. Meanwhile, more of the work goes to agents that can’t hear the explanation at all. If the context isn’t written on the work, then neither the agent nor the next person has it.

What one company’s numbers show

On October 16, Anthropic’s Economics team published a report on how employment is changing within Anthropic, using internal data on headcount, hiring, AI usage, calendars and communications, as well as interviews with employees. It’s one company, an AI lab that describes itself as at the frontier of AI adoption, and the authors see it as a possible leading indicator for the wider economy. They also point out that many of its employment practices can’t be replicated elsewhere. That makes it an early look rather than a representative sample of the industry.

A few of its findings point to where context lives.

• A smaller junior share. The junior share of employees in Anthropic’s technical teams has dropped from 21 percent to 14 percent since early 2025. The junior share of technical hires dropped more sharply, from 27 percent to 9 percent. The report doesn’t define junior; it refers to lower-band technical roles. It gives several reasons for the shift, including managers who said they were hiring less because of AI, and notes that the company was growing fast at the same time. We cite the figures, not a cause.
• More agent hours. In March 2026, agent hours (including autonomous agents) passed employee hours. Counting only the agents employees directed themselves, by August those agents were working six times as many hours as the people directing them.
• Agents wait on people. About 80 percent of interactive session time is the agent waiting for a person. One engineer described people as “bottlenecking the agents.”
• More written instructions. Written standing instructions for agents grew from a few hundred in July 2025 to 8,500 a year later.
• More meta-work. What the authors call meta-work (building skills, plans and reviews for other agents, monitoring agent pipelines, and documenting how work gets done) rose from 10 percent of employees’ interactive sessions in fall 2025 to 22 percent in spring 2026, based on a sample of session summaries.

The authors also talk about what happens to decisions. “If a decision is made in an in-person meeting, and no notes or report-out appears, agents are missing crucial context for updating their goals and assumptions.” Private work in unlogged meetings and direct messages, they write, is “invisible, confusing and discouraged” in an AI-heavy workplace like theirs. That’s their description of how the company works, not a measurement, but it’s the same point from inside a team that already runs on agents. Read Anthropic’s report on how employment is changing at Anthropic.

The report makes no mention of mentoring, onboarding or how new people learn. The link we’re proposing, that fewer juniors means less context passed on by asking, is ours.

Anthropic isn’t the only organization to see a shift in early-career hiring. The August 2026 revision of Stanford’s “Canaries in the Coal Mine” paper, using payroll data through June 2026, finds employment of 22- to 25-year-olds in AI-exposed occupations 19 percent below where it would be had it kept pace with less-exposed peers. There’s no comparable gap for experienced workers. The authors call these descriptive indicators rather than causal estimates, and the occupations are broader than software. Read the Stanford Digital Economy Lab paper.

Illustrative example: a decision made in a meeting

Previous articles in this series followed one change: an “Account reference” column at the end of the account activity export. The one open question for the product owner was whether an account with no reference should show a blank cell or a placeholder. It was still open when a support ticket came in saying the new column was blank and the customer’s import was rejecting those rows.

Illustrative example. The meeting, the work items and the details are invented.

In the next planning meeting, the product owner settles it. Blank stays. A placeholder such as “N/A” would be read by customers’ imports as a real reference. A customer who wants a value in every row is asking for a change, not reporting a bug. Everyone in the room agrees, and the meeting moves on.

Three weeks later, a second customer reports the same thing, and an agent picks it up.

If the decision stays in the meeting

The requirement states: Open question: blank cell or placeholder? The product owner answers.
The new ticket states: “Blank rows break our import. Please fill them in.”
What the agent does: Fills the blank cells with a placeholder. It’s a minor change, and the tests still pass.
What the reviewer sees: A sensible fix. The engineer who reviewed it joined the team after that meeting.
What happens: The decision is reversed without anyone deciding to reverse it.

If it’s written on the requirement

Blank references (decided): Blank cell for an account with no reference. The product owner decided in planning.
Ruled out: A placeholder, because customers’ imports would read it as a reference.
Follow-on: A request for a value on every row is a change request. The product owner sets the priority.
What the agent does: Leaves the export as is and sends the ticket back as a change request, with the decision linked.
What the next engineer sees: The same line, with a name and a reason.

Nobody was careless in the first version. The agent worked from what it could see, and so did the reviewer. The only difference is one entry on the requirement, written at the time of the decision.

What to write down, and where

Most of this doesn’t need a new document. It needs a few lines in the place the work already lives: the requirement, the issue or the PR. Meeting notes are fine as a source, as long as the decision also gets written into the work it affects.

Decisions

What to write: The decision, who made it and why.
Where: On the work item or requirement it affects.

Open questions

What to write: The question, who answers it, and whether it blocks the work.
Where: On the work item. Close it with the answer; don’t delete it.

The customer’s words

What to write: The request or report as the customer wrote it, not a summary.
Where: Linked from the work item, so the agent and the engineer are looking at the same thing.

What was ruled out

What to write: The options you considered and didn’t take, and the reason.
Where: Next to the decision.

Michael Nygard made the case for this in 2011, in the post that introduced architecture decision records. If you come across a decision without the reasoning behind it, you can either accept it blindly or reverse it blindly. In his words: “It’s better to avoid either blind acceptance or blind reversal.” He proposed keeping the records in the project repository. Read Nygard on documenting architecture decisions. He was writing about architecture, but the same applies to a product owner’s answer about a blank cell.

Standing instructions

What to write: What applies across tasks: build and test commands, conventions, known pitfalls, and the reasons for them.
Where: The repository’s instruction files, such as CLAUDE.md or AGENTS.md, under version control.

Keep it all short, and keep it current. The Anthropic report has a small example of what stale context can do: an employee’s name on a months-old document meant agents kept coming to them with requests for t-shirts and mugs “long after their responsibilities had changed.”

Where Blacktops fits

You don’t need a particular tool for any of this. A line on the work item with a name and a reason is enough to get started.

The harder part is keeping it linked as the work moves. A decision is made in a meeting, an answer to an open question comes in through chat, and the work item never hears about it. Someone still has to put that decision on the work. Blacktops is the Agentic SDLC Platform built to keep the customer’s question connected to the work. It keeps one thread from the customer’s question to the delivered resolution: the approved requirement, the agent’s work, the evidence, each decision and who made it, and the update back to the customer. Agents do the work between the decisions, and people make the decisions. We call the operating model Continuous Agentic Software Delivery™, or Blacktops CASD™.

After your next planning meeting, take each decision and check that the work item it affects says so.

Name one decision from your last planning meeting that your agents can’t see.

Related: What a support ticket needs before it reaches engineering shows the ticket that raised the blank-reference question. What an agent-ready requirement actually contains writes the export requirement out in full, including that open question.

Continuous Agentic Software Delivery, CASD and Blacktops CASD are trademarks of Blacktops, Inc.