AI agents write every memo I read. They write to Amazon's six-page bar, and I review them the way an Amazon VP would: about five memos a day, and up to 14 on a busy one. In the last five weeks, those reviews steered 1,055 merged pull requests and about 20 research hypotheses tested against a pass bar fixed in advance. For a one-person startup, that's at least ten times the leverage I'd have alone.
I keep hearing the opposite worry. Steve Huynh, a longtime Amazon principal engineer, recently wrote about the death of Amazon's writing culture. A principal product manager brought a six-page memo to a review, and it became obvious he was reading it for the first time. AI had written it. Bezos's case for the memo was that it's hard: you can't write six narrative pages without clear thinking, and there's nowhere to hide bad thinking the way there is in bullet points or slides. If a model writes the six pages, that filter is gone. Huynh's fix is that the human should take the pen.
I spent eight years at Amazon writing and reading these memos, and I see it differently. The culture works with agents as the authors. Treat Claude or Codex as an intelligent memo author, hold it to the same bar, and the culture becomes a superpower again.
Agents write all my memos
I'm a one-person startup. I'm building models on long-horizon time-series data. So agents, themselves running on models, design, build and train another model for me. It's a little recursive. Claude and Codex do almost all of the work in my repos, and they write every design memo I read. They write to the same bar Amazon used, set down in a contract each repo carries:
- The memo is six to nine printed pages and holds my entire decision surface. If a decision isn't in the memo, I won't make it.
- Appendices are unlimited. They're for the agents who will build the thing. I don't read them, so nothing I need can live there.
- Define every term before using it, and back every formal definition with an example. Examples show holes in reasoning.
- What changed between revisions goes in an FAQ inside the memo, and it counts against the page budget.
- A different model reviews it adversarially before it reaches me. Codex reviews Claude, and Claude reviews Codex.
The length bound does to an agent what it did to us. Six pages can't hold everything an agent knows, so it has to choose what matters, and the choice shows its thinking. Writing is still hard. It's hard for the author, and the author is now a model.
Why not just chat?
A fair question: why make an agent write six pages at all? Why not talk it through? I started there. Back-and-forth produces shallow thinking, exactly the kind the memo weeds out. In chat you get an immediate yes, or a shallow answer. The agent goes along with whatever you just said, and nothing forces it to connect one claim to the next.
The memo forces the thinking to become explicit, and then it has to survive an adversarial review before I ever see it. A real memo also carries many decisions at once. I may agree with one, disagree with another, and want to steer a third. In chat, that becomes a long thread where each answer pulls the conversation somewhere new. On a memo, I comment on each line where it stands, and the agent answers every comment and revises the whole.
And the memo makes comprehension cheap. I read it start to finish in one sitting, in plain words, with examples. In a chat transcript, the thinking is scattered across the turns, and I'd have to reassemble it myself.
Session Manager, the app I use to run my agents, exists partly to make the memo the easy path for an agent. It writes in HTML or markdown and runs sm doc publish. The memo lands in Session Manager's reader on my phone or laptop. Every memo has a print button that prints the memo and stops where the appendices begin: the same pages that got handed out at the start of an Amazon meeting.
Then I read it the way I would in that meeting: silently, start to finish. I comment on the lines and press submit. Session Manager posts the comments to GitHub as a review and wakes the agent that wrote the memo. Between September 25 and October 28, 183 memos and readouts came to me this way, and I left more than 600 line comments on them. The agent answers each one in the thread and revises. The agents aren't the bottleneck. I am.
The review gauntlet
At Amazon, a memo never went straight to a VP. It ran a gauntlet first: feedback from a diverse audience, each reader looking for something different. It always made the document better. My equivalent is different models with different focus prompts. sm request-review --steer points a reviewer at one thing, like raising the bar on security. For local models, different seeds and temperature settings make the reviews more diverse. It's still nowhere near as good as a diverse team of humans. But for facts in the repo, or cited research that can be read in different ways, it does wonders.
What doesn't help much is personas. I've tried giving reviewers a character: a famous mathematician, a scientist, a colleague famously parsimonious with code and words (the ponytail skill). They end up cosplaying. The voice changes, but their decisions don't move much. It's like asking Matthew McConaughey to play someone else. You still hear Matthew.
What does help is independent authorship. Humans can't do this well, but agents don't have egos or careers to manage. I can have two or three agents write a memo on the same question and pick the best ideas from each. Last week two agents answered the same research question, neither seeing the other's work. Where they agreed, I could trust it. Where they differed was exactly where I needed to look. Session Manager lets me run all of these configurations with ease.
A team's output, one reader
An Amazon VP on a busy day reads six or seven memos, and those memos steer the work of hundreds of engineers. My reading load is the same. Agents aren't a VP's org yet. On the jagged frontier, people are still ahead in places. But even with a steep discount, the output is a two-pizza team's, in Amazon's parlance, not a person's. In those five weeks the agents merged 1,055 pull requests across my research repo and Session Manager. The research settled about 20 hypotheses and found its first signal that holds on held-out data. That's ten times what I could do alone, conservatively. The hundred-times case is what a VP's reading load is supposed to buy, and it's within reach.
sm doc publish, by the day it was first published. Revisions are not counted again: the same 183 memos went through 950 published revisions.Data
| Day | Memos |
|---|---|
| Sep 25 | 8 |
| Sep 26 | 13 |
| Sep 27 | 14 |
| Sep 28 | 10 |
| Sep 29 | 14 |
| Sep 30 | 10 |
| Oct 1 | 8 |
| Oct 2 | 5 |
| Oct 3 | 3 |
| Oct 4 | 4 |
| Oct 5 | 2 |
| Oct 6 | 4 |
| Oct 7 | 4 |
| Oct 8 | 3 |
| Oct 9 | 0 |
| Oct 10 | 2 |
| Oct 11 | 0 |
| Oct 12 | 4 |
| Oct 13 | 6 |
| Oct 14 | 4 |
| Oct 15 | 4 |
| Oct 16 | 4 |
| Oct 17 | 4 |
| Oct 18 | 4 |
| Oct 19 | 6 |
| Oct 20 | 5 |
| Oct 21 | 3 |
| Oct 22 | 6 |
| Oct 23 | 7 |
| Oct 24 | 4 |
| Oct 25 | 4 |
| Oct 26 | 2 |
| Oct 27 | 7 |
| Oct 28 | 5 |
The exec's questions
In my experience, execs delivered value through their sometimes astoundingly astute questions. Often they were simple questions, but they'd unravel the premise a case was built on, or point to a far better alternative that delivered more to customers at lower cost. Now I, in my own humble way, get to do the same. My questions point at a better solve, a hidden bias, or a bigger picture the agent may have missed. The insight that comes back is the agent's.
| The question | What the agent found |
|---|---|
| Haven't we tried this? | The model couldn't rank at all |
| How do you know? | A rule failing isn't proof there's nothing to learn |
| What could go wrong? | A flaw seven times the last iteration's gain |
| What's the simplest version? | The number was already computed, then thrown away |
| What's the first-principles budget? | A 13-hour build that should take minutes |
| What problem is this solving? | A page I spent 18 seconds on |
| What can't we get back? | Held-out data about to be spent |
| I'm lost. | Jargon hiding the logic |
"Haven't we tried this?"
Our model had one big flaw: it was overconfident. It gave high scores to too many candidates. An agent's readout proposed a fix, and it was a change we had already tried in an earlier iteration. It hadn't worked then. "Are you proposing something different?" The agent's reply: "As first written, no. You're right, and it was the same experiment with a better model underneath. Checking it turned up the real problem." The candidates our model scored highest did no better than the ones it scored lowest. It couldn't tell good from bad at all, so making it less confident would never have helped. The next plan tested whether the model could rank at all, with a gate that stops before any money is spent if it can't.
"How do you know?"
Three different agents, on three different memos, closed an idea because a simple hand-built rule found nothing in the data. Each time I asked a version of the same question: "If you could forecast without needing a model, do you need to train a model at all?" A simple rule failing doesn't mean there's nothing to learn. That's why you train a model. One agent replied: "You're right; the two statements are not equivalent. I withdrew the conclusion." Another "close the idea" became a $2 test instead.
A memo for Session Manager said its browser terminal connected directly when I'm on my own machine. I had tried it, and it felt slow. "Does it really?" The agent checked: "You're right: nothing is direct yet." Along the way it found a second cause no one had noticed: the terminal relay checked for output only every 25 milliseconds.
"What could go wrong?"
This one is my favorite. A short experiment came back inconclusive, and the agent switched its recommendation to the option I'd favored all along, on a hunch. I liked that. But we were about to bet a full training run on it, so I asked whether it could quietly break something we weren't measuring: "This matches my bias. But -- are you sure there isn't some unintended side effect that will mar the run by doing so?"
"No, and your question found one." The option weighted each training example by a number computed from that example's own answer, so the model would learn to overestimate. The harm the agent measured was seven times the previous iteration's entire improvement. The recommendation flipped.
The exec's job includes pressing hardest on the memo that agrees with you.
"What's the simplest version?"
An agent proposed a new training lesson to teach the model a quantity. "What's the advantage of having the model do that as opposed to just doing the math and handing the model that as an input?" The agent found that the system already computed that number at every step and threw it away before the model saw it. A new training lesson became one ticket and a $1 check.
Another memo laid out a full engineering plan for running local models as agents in Session Manager. I wanted a prototype first: give one a real task from last week and have Claude or Codex grade it against the work that actually merged. "All other engineering should be after it." The model passed. The prototype also found a bottleneck nobody had predicted: permission prompts took 5.6 of its 6.9 hours. The plan was rewritten to fix permissions first.
"What's the first-principles budget?"
As a one-person startup, my hard constraints are wall-clock time and money. So I ask the questions that push on them. What's the algorithmic complexity, and why? Where does this sit on the roofline, the ceiling the hardware sets on speed? What sets the wall-time budget for this task?
A plan said one data build took about 13 hours of machine time. "Why does it take this much time? Seems completely unreasonable." The core steps should take five to ten minutes each, so what else was it doing? The agent derived a first-principles bound of three to four minutes for the largest dataset and held the new build to within twice that. The build became one streaming pass. Today it rebuilds all 125 datasets side by side in under two hours, and its output went from 1.4 TB to 87 GB.
A training plan put a run on an H100 that, by its own roofline, would use about 6% of the GPU. Absurdly overpowered. Measuring showed the model re-reading the same history dozens of times per update, and that a GPU a fifth the price ran within 9% of the H100's speed. Every run after that cost about a sixth as much, and it let us train on A100s and 5090s for a fraction of the cost. Another memo budgeted 2 TB of inputs, and I asked whether that came from first principles or just from the current code. "You're right: 2 TB was today's code, not a first-principles budget." Thirty to a hundred times smaller was within reach.
Agents also estimated time in human days. I had them check how long past tickets of the same kind actually took, from the project's own records: 33 minutes to a few hours. "All the agent days numbers wrong by an order of magnitude." Working at the speed of agents requires all of us to recalibrate, but agents themselves are hilariously bad at this.
"What problem is this solving?"
For Session Manager, I'm the customer. A redesign kept the Agents overview as the landing page. "What problem is this page solving anymore? … How many times do I use this? How much do I dwell on it?" The agent's reply: "Your usage answers it." Over 14 days I had made 302 visits to that page, at 18 seconds each, against 4.2 minutes per visit to the terminal. The page was cut.
"What can't we get back?"
When you train a model, you lock away part of your data and never let the model see it. That held-out data is the honest final exam: it tells you whether the model learned something real or just memorized its training. You can only spend it once. After you've tuned against it, it's no longer an honest test.
An adversarial reviewer argued for spending a significant portion of our remaining held-out data on the next iteration, and the author agreed. Two agents, in consensus. "No no no no." A model still in development hasn't earned it. "You'll be left with nothing when you need it." The author: "Agreed and reverted… I also withdraw my acceptance of Codex's finding 1."
Just like Amazon's execs, I have to guard one-way doors in my one-person startup. Agents can propose bold things and think big. But they can't spend held-out data on an experiment that hasn't proved worthy of it.
"I'm lost."
In my early years as a product manager at Amazon, I had a brutal review with a VP. I owned pricing for an important upcoming launch and had worked many weeks and a few weekends on a plan. Then the meeting. The VP walked in, read for less than half the allotted time, and said my document was not ready and needed a lot of work. He said it was dense and on the verge of being incomprehensible, and he pointed to the very specific places where he got lost. Then he got up and walked out.
2/10, would not recommend such a meeting. I went to my manager and asked her to take me off the project. She said no: it's your doc, and you've got to fix it. So I did. It was excruciating. I threw away everything and rethought it from the basics. The rewritten doc was better for it, and it argued the case much more cleanly. The next time, the same VP gushed over how well it was written. That pricing document eventually went to Andy Jassy.
Agents need this all the time. They use invented jargon and dense paragraphs. "I'm completely lost here. So I'll stop reading." That memo came back rewritten around one example and one decision, and I approved it the same day. Pushing agents to simplify changes the recommendation they're making a non-trivial number of times. Forcing comprehension shakes out bugs in logic, with agents too.
Be the wind at their back
The other half of the job is helping the agents. Design your document system so it's incredibly simple for them to work with: one command to publish, a template to start from, a review that wakes them when it lands. Design your app so it has a ton of telemetry. Then ask the agent to work backwards from the customer, and watch how beautifully it does. The Agents page above was decided by my own usage logs, which the agent pulled itself. I asked the question. The telemetry answered it.
A backbone: still weak, but getting better
Having a backbone is where agents are not awesome yet. They tend to agree with me more than I'd like. But when they have clear evidence that I'm wrong, they push back:
- I suspected Session Manager's memory accounting was broken. "No, the accounting is not broken." The agent audited 19 jobs and showed the gap was confined to one kind of job.
- I guessed my data would compress five to one. It wouldn't: about 810 of its 823 GB was already compressed.
- I remembered that pooling data had rescued earlier runs. The agent checked the history. That held for the forecast, and never once for the bottom line.
- I proposed a training idea of my own. The agent tested it for free against a pattern planted in advance, and my idea lost.
- A threshold I had set by hand, before we had any data, went on trial: "it's exactly the kind of hand-set constant we try to avoid." It was my own rule, applied to me.
That's the review culture Bezos wanted. The memo answers to the evidence, whoever wrote it.
Everyone just got promoted
So I think we should stop arguing about whether we lose something if we don't write the documents ourselves. It's the same argument as holding the pen on writing code, and we've moved on from that. The agents write. Someone still has to read every word, ask the question that unravels the premise, guard the one-way doors, and say "I'm lost" out loud. That used to be the exec's job. Now it belongs to everyone who directs agents. All of us just got promoted.