Picture this. You're the founder of a 30-person startup. You believe in "radical transparency." Every Wednesday at 4 p.m., you host an all-hands. This Wednesday, you calmly share that the board has flagged concerns about the runway model and is reviewing whether the next milestone is achievable.

You phrase it carefully. You take questions. The engineers nod. The marketers ask intelligent questions about strategy. Everyone says they appreciate the transparency. You go home feeling like you've done the job.

For the next nine days, your engineering team ships absolutely nothing substantive.

They check TechCrunch more than they check the codebase. Two senior engineers quietly update their LinkedIn profiles. The lead designer asks her partner if maybe they should hold off on the kitchen renovation. Nobody mentions the all-hands. Nobody says they're worried.

You thought you did the responsible thing. You did the exact opposite.

The Cognitive Light Cone

There is a term from developmental biology that explains this perfectly. A Tufts biologist named Michael Levin talks about the cognitive light cone — the spatiotemporal size of the biggest goal an entity is capable of pursuing. Not the things it can physically touch, but the goals it can hold in its mind.

A single cell has a tiny cognitive light cone: its goals operate over micrometers and minutes. A dog's is bigger: the perimeter of its yard, the food bowl, yesterday's walk. A human's is enormous. In fact, Levin notes that humans might be the only species capable of holding goals that are structurally impossible for us to attain. World peace. What happens when the sun burns out. The welfare of strangers a continent away.

Levin flags this as more than just a biological curiosity. It produces a unique, crushing psychological pressure: the experience of holding a goal you cannot reach.

This is exactly what happens when you give your IC engineer the runway update.

The board's runway model is well within a founder's cognitive light cone. The founder can pursue it as a goal, act on it, and pull levers to fix it. But when you hand that same trajectory to an engineer, it becomes a goal she is forced to hold in her head without any levers to influence it. She's been handed a goal that is the wrong size for her position. The light cone expands, but her action range does not.

You didn't transfer agency. You transferred unresolvable anxiety.

Why "Awareness" Isn't Free

In 1908, psychologists Yerkes and Dodson mapped out a concept that sits in every undergrad psych textbook: performance on cognitive tasks is an inverted U-curve based on arousal. Too little arousal? You're bored, slow, and sloppy. Too much? You're anxious, frantic, and sloppy. Peak performance lives in the middle.

When you hand someone a goal they can act on, you raise arousal in a productive way. They point at the thing. They do the thing. Arousal drops. Performance holds.

But when you hand them a goal they can hold but cannot reach, you spike their arousal with nowhere to put it. They ruminate. They doomscroll Slack. They write overly long emails. They make trivial decisions worse. And because the goal is fundamentally unresolvable from their position on the org chart, the arousal never decays.

Fifty years ago, cognitive scientist Herb Simon said it cleanly: A wealth of information creates a poverty of attention. Telling your team things they cannot act upon costs them the attention they desperately need to do the things they can.

The EM as a Filter, Not a Conduit

Over twenty years of working at startups, I have come to the view that the single most vital job of an Engineering Manager is to be a filter.

Most companies run on the conduit model. Information enters the top, the EM relays it downward in the name of "alignment" or "transparency," and the team is left to metabolize the stress.

The filter model operates differently. Information hits the EM. The EM holds it. The EM decides what is strictly actionable, translates it, and eats the rest.

The Conduit says: "The board is reviewing our runway."
The Filter says: "Our absolute top priorities this sprint are these two specific epics."
The Conduit says: "The CEO is terrified about Q3 churn."
The Filter says: "We are heavily prioritizing the onboarding flow this month."

This is not lying to your team. It is load-balancing.

Spotting the Difference

You can always spot a conduit manager's team the week after major company news. They are distracted. Velocity plummets. Résumés get polished. A few ambitious ICs try to "help" by getting involved in strategic decisions wildly above their pay grade—which is the most expensive form of distraction, because it forces senior leadership to manage the help.

A filter manager's team is heads-down. When the dust settles, they are surprised to learn what was happening behind the scenes. Some might initially feel betrayed. Most, upon reflection, understand exactly why they were shielded.

Can the filter model be abused? Yes. Bad managers use it to hoard power, hide toxic behavior, or protect a fiefdom. But the right response to those failure modes isn't to abandon filtering for reckless disclosure. The response is to be a leader who filters with such high integrity that your team trusts your shield, even when they don't know what it's blocking.

The Executive Playbook

If you are an EM or an engineering leader, here is what filtering looks like in practice:

Default to absorbing, not forwarding: When you receive executive information, the first question isn't "who needs to hear this?" It's "is there anything in this my team can actually influence?"

Translate, don't quote: Convert anxiety-inducing inputs into action-shaped outputs.

Triage by action range: If they can act on it, share it. If they can't, you reroute it to the limited group who can or you carry it.

Resist the transparency flex: "Radical candor" means giving honest feedback. It does not mean telling everyone everything.

Schedule the bad news: When bad news must be shared, batch it and deliver it with the action items already mapped out. Surprise, drip-fed anxiety is the absolute worst kind.

Be honest about scope: You aren't lying when you say, "This is not something your role can act on, and I am not going to make you carry it."

The Truth

This job is incredibly hard. You will carry weight your team never sees. You will absorb worry that has no outlet. You will occasionally be accused of being closed-off when you are actively bleeding to protect them.

Some of your team will resent the filter. Others will figure it out and thank you years later. Both will happen, because that is the job.

"46% of developers distrust AI output" is not a "How do we get the team to believe?" problem. We are engineers. We're not in the business of managing vibes. The value of AI on a task = generation cost saved − verification cost incurred.

The Only Equation That Matters

Stop asking "Can AI do this?" Capability is the model vendor's problem and it is improving at warp speed. Start asking "How cheaply can we verify this?" That part is yours, and it's investable.

Property-based tests, strong typing, contract tests, canary deploys, shadow traffic, feature flags — these used to be "good engineering hygiene." Now they're leverage. Every dollar that makes correctness cheap to check expands the surface area where AI is allowed to touch the codebase without turning into a liability. Make verification so cheap that trust becomes irrelevant. Trust follows verifiability.

Your Trust Map Resets Every Model Release

Trust isn't a scalar. It's not "do we trust AI?" It's a map: which task types, which corners of the codebase, which failure modes. Build an eval suite over your tasks, your codebase, and rerun it on every model release. When the map lives in evals, a model upgrade is no big deal - you're ready.

Ownership of Trust

Juniors over-trust because they can't verify. Seniors under-trust for identity reasons. The dangerous middle is the people skilled enough to skim-review and not yet scarred enough to actually check. Give SME engineers authorship of the verification harness. Convert the identity stake from "I am the one who writes the correct version" to "I am the one who defines what correct looks like." Same value, better system.

Put Trust in the Pipeline, Not the Person

The end state the frontier has already reached looks like this: CI gates that AI-generated code must pass. Eval suites that mechanically define what the current model is allowed to touch. Sampled deep review at a rate set by measured defect rates. And increasingly the verification layer itself is AI — models reviewing models, adversarial passes — with humans auditing the checker rather than every single output.

AI models will continue to improve at an insane pace. Build solid quality checks today so your business can improve at the same insane pace tomorrow.

"AI code is 90% right. The last 10%—error handling, concurrency, security, performance under load—still requires human expertise." Bollocks.

What people call the irreducible last 10% is not some mystical engineering judgment that only a senior human can supply. It is just undocumented memory: tribal knowledge that lives in Slack threads, post-mortems, tribal conventions about how this system actually behaves under load, the quiet constraints that were decided in a meeting three years ago.

State-of-the-art models do not fail at engineering. They fail at your context. The size of the gap is a direct measurement of how much of the system's real specification still lives only in people's heads. What we romanticize as "irreducible human judgment" is, in the majority of cases, a simple writing backlog.

The Pattern Is Universal (and Slightly Humiliating)

Watch how people actually use AI:

• Non-specialists say the models are already good enough for most work.

• Specialists say the models are impressive… except in their domain, where the output is obviously incomplete, naïve, or dangerous.

The same person who trusts an LLM to draft legal memos, marketing copy, or infrastructure-as-code will insist that in their particular specialty the last 10% is sacred. This is not evidence of unique human genius. It is evidence that the specialist has more private context than everyone else—and has not yet externalized it.

Frontier teams treat the gap as a conversion problem, not a capability problem:

incident → written constraint → context repository → eval case

Yes, genuinely novel failure modes and required adversarial creativity against surfaces nobody has attacked yet still exist. That residual is real. It is also far smaller than the current narrative allows.

Same Model. Different Harness. Wildly Different Outcomes.

Two teams can run identical weights and get completely different production results. The difference is not the model. It is the scaffolding around it:

• Living context repositories that the model can actually read

• Eval suites that encode the real constraints of the system

• Incident feedback loops that turn every surprise into durable documentation

• Verification infrastructure that catches the remaining 10% before it ships

The model is the engine. The harness is the rest of the car.

Automating Context

Don't bother sitting down and writing a perfect knowledge base from scratch.

Instead, record most of your internal calls and conversations (with appropriate consent and policy). Feed the transcripts to an AI whose only job is to extract the relevant constraints, decisions, failure modes, and tribal conventions, then file them into a context repository organized the way your models prefer to consume information. Keep the structure flat, searchable, and versioned. Prefer short, declarative statements over narrative. Tag by system, severity, and last-verified date.

Within a few weeks the repository becomes the missing 10%. The model stops hallucinating the parts that used to live only in people's heads. The "human expertise" gap shrinks to the genuinely novel edge cases—the ones that actually deserve human attention.

This is not a theoretical future. Teams that treat context as a first-class engineering artifact already ship with far less drama. The rest of us are still arguing about the last 10% while the real work—writing the system down so the model can see it—remains undone.

The models are already good enough. The remaining gap is your documentation.

You've bought AI tools, scaffolded the system, onboarded the teams, but adoption is happening at a seemingly glacial pace. Here are a few ideas you might try to grease the wheels:

Loop in Finance

Finance has seen one hundred AI vision decks and zero P&L transition models. Help them see the future.

Engineer salaries on R&D work frequently get capitalized—turned into an asset and amortized—under software capitalization rules (and, in the U.S., mandatory R&D amortization under Section 174). Inference spend is plain opex. It hits the P&L immediately.

So when you replace $2M of capitalizable engineering labor with $300K of inference, current-year reported earnings can look worse even though the real cost just collapsed. Your CFO looks at the plan and sees an earnings dip in year one, a crossover, and then a structurally lower cost base. They're not wrong.

Write out your strategic plan to paper over the dip with harness development—evals, context repositories, agent infrastructure. That work is itself capitalizable as internally developed software. The accounting asymmetry between "engineer building features" and "engineer building the system that builds features" is mostly a categorization fight, and Finance owns the categories.

Agree on one non-GAAP metric to report alongside the official numbers—output per fully-loaded dollar—so the board can see the real trajectory while GAAP works through the hangover. Helping your CFO co-author the transition model ensures he feels comfortable defending it. If finance is on your side, no one can stop you.

Loop in HR

Legacy company metrics still assume output scales with humans. Promotions are largely based on scope, span, and the complexity of herding other humans. Leading six people through a multi-quarter migration is still more likely to get you promoted than shipping the same migration alone in three weeks with an agent fleet.

To the existing HR system, agents register as smaller scope, fewer dependencies, and no one coordinated. Until "span of agency"—how much output you can actually be accountable for—replaces "span of control" in the leveling rubric, AI adoption will keep stalling while everyone performs the old playbook.

If you want to move the needle this quarter, ask your friendly HR leader to add a "leverage case" packet to promotion evidence: output shipped, harness built, verification responsibility carried. Then actually promote one visibly AI-native engineer on that basis. Once someone actually gets paid for working the new way, people will start taking your strategy decks seriously.

Loop in Management

Let's be honest about what most managers actually do: aggregate information upward and disaggregate instructions downward. Management is a routing layer for context. That is exactly the function a well-maintained context repository plus agents performs.

The new senior roles—harness owner, context steward, verification lead—are the highest-leverage jobs in an AI-native org. Your best managers are the natural candidates because they are already the org's context-routing layer. Show them how writing down what they route turns their tribal knowledge into compounding momentum for the organization and builds their next role in the process.

You might also try running one reference team openly—small, AI-native, real production surface—and publishing their numbers internally. Envy is a change-management program that runs itself.

Don’t Forget Your Quietest Engineers

If you are already running an AI-native team, you know the secret: your best engineers are heavily AI-leveraged and they are hiding it from you.

If a task scoped at two weeks with the sanctioned tools takes two days with covert AI, revealing that fact gets them a policy violation and more work. So they deliver in nine days as expected and bank the margin. Why wouldn't they?

Consequently every internal pilot is corrupted. That 15% lift you're celebrating is not the delta between "No AI" and "AI." It is the delta between covert adoption and open adoption.

Give them a Scoping Amnesty. Don't punish the saved time with more work. Suspend judgment on the methods. Let them use the reclaimed time for harness investment—better evals, context repo work, tooling. Now the engineer who reveals a 5x speedup gets something for it instead of losing something.

Good Luck and Godspeed

The entire AI transition is a repricing exercise. Your organization currently prices coordination. You need it to price leverage.

Prices only move when someone is visibly paid the new way. Everything else is commentary, slide decks, and another pilot that won't turn into a funded project.

Fix the incentives before your next strategy offsite.

You've been handed the assignment: some version of: "Put together our long-term vision for AI agents."

And there's so much noise. Which model is best this week. What your competitors are claiming. Whether humans are even still relevant. How are you supposed to work out what's affordable, what's buildable with the team you already have, and what actually fits your business model — while the ground keeps shifting under your feet?

I'll tell you how I do it, which I mostly learned from Rhythm Systems — an incredible company who you should definitely call if you're ever trying to firm up your strategy, align your entire exec team and organization to it, and knock your goals out of the park quarter after quarter.

I just use Claude Sonnet for this exercise currently (we're not doing any rocket science here), but use whatever AI model you prefer. Fill in the [COMPANY] and [DATE] placeholders with your own data.

Prompt 1: Reconnaissance

Research [COMPANY] as of [DATE]. I'm building a long-term AI agent product vision and need to size up the company first. Answer five questions, citing sources and flagging anything you couldn't verify:

1. Funding position — who owns or funds them, and what does that structure imply about appetite for long-horizon bets? Estimate the investors' likely exit window.

2. Business model — how do they make money, precisely? Pricing, secondary revenue lines, customer count.

3. Scale — headcount, trajectory, recent executive hires or departures.

4. AI maturity — what have they actually shipped, native versus vendor-supplied? Do they employ ML engineers? What have direct competitors shipped?

5. Strategic moves — M&A, platform plays, ambitions stated on the record.

Keep it under 600 words.

The output from this prompt will help ensure that your vision is fundable and buildable. Doing unglamorous homework before having opinions is the difference between a junior employee and a senior one.

Prompt 2: Read the weather

From that research, derive the 4–6 constraints that should dictate any AI agent strategy for [COMPANY]. For each: the fact, then the strategic implication in one line. Cover at minimum — the investor clock, the AI capability gap (build versus buy posture), the revenue shape (which metrics an agent must move to matter at all), the proprietary data asset, and the competitive window.

Every project has constraints. Your company has no ML engineers? Your vision should not include training and deploying AI models this quarter. The difference between a junior employee and a senior one is knowing to identify the constraint and name the mitigation: Milestone 1 might be to partner with a model provider, and hire or upskill one employee to own the unit economics of that partnership.

Prompt 3: Draw the mountain

Build a summit map:

• The summit, 7–10 years out. One audacious, measurable end state. Big enough to organize a decade, concrete enough to be proven wrong.

• Three basecamps, working backward, 2–3 years apart. Each gets a name, a window, a one-line thesis, and an explicit link to the investor clock: which basecamp pays the current investors, and which ones are the acquirer's or next round's upside story.

• A "required to reach" list per basecamp — what must be shipped, hired, built, priced, and measured.

Route everything around the constraints. If a basecamp violates one, flag it. Don't smooth it over.

I use the @mirohq MCP to draw, but you can use Excalidraw or whatever you like. The important part here is "Don't smooth it over." Junior work hides tension to make the deck flow. Principal work diplomatically puts the tension on the slide — these are actual decisions to be made, and ignoring them will be the death of your plan.

Prompt 4: One click down — operations and cost

For each basecamp, specify agent-operations guidance across six dimensions: runtime placement, agent identity and licensing, cost economics (model cascading, prompt caching, unit-economics rules), security and data flow, measurement, and change management.

Name the two dimensions that are primary at each altitude. Estimate annual cost as a range and flag every assumption. Then state which cost-discipline decisions must be architected early because they cannot be retrofitted at scale.

This starts to turn the vision into a plan. Anyone can say "AI agents." Saying "roughly $2–4M a year by 2030, and here's the decision we have to make in Q1 or the margins never work" is what gets you in the room where budgets happen — a room you definitely want to be in if you desire authority over the work. The outputs here are just suggestions, but they will provide the shape of the decisions you're being asked to make. Just go ahead and get them on a page, and you can massage them from here.

Prompt 5: The picture

Create a minimalist flat-design vector illustration for a strategy slide (16:9). A single stylized mountain in your brand color, built from layered silhouettes. Three flat ledges on the ascending face, connected by a thin dashed accent-color trail to a small flag at the summit. Generous negative space above and beside the mountain for text overlay. Absolutely no text, letters, numbers, or labels anywhere in the image.

Ban text explicitly, in those words. Image models will cheerfully invent labels that say things like "BASECAMP TWO." Annoying. You layer the real ones on your the deck.

The output

I'm obsessed with this Rhythm Systems-style mountain graphic method for communicating high level strategy and how we'll get there, in a way that feels challenging yet achievable. Look at the density of information you get in one slide.

This first draft is never the final draft, but it takes under an hour to build, helps me organize the problem, surface challenges in bite-sized chunks, and reveals things that maybe I hadn't thought of yet. I love getting things out of my head and into Miro where I can collaborate on them with lots of stakeholders and advisors before finalizing our vision.

If this was helpful to you, let me know what improvements you end up making to the process. We're all learning together, no gatekeeping.

"How do I patent my product so nobody copies it?"

I've gotten this question a few times this month. Always from accomplished people with real careers and deep expertise, building software for the first time.

The short answer is you probably can't, and it probably wouldn't help. Alice v. CLS Bank (2014) killed the idea that you can patent "your idea on a computer." If you assembled your product from AI coding agents and big thoughts, there's likely nothing novel enough to file on.

But the deeper answer is the one I actually want to give, because what's common sense inside our little bubble isn't intuitive anywhere outside it.

Software Is Not a Thing You Build. It's a Thing You Feed.

A patent protects an artifact. In software, artifacts are short-lived.

Code rots even when you don't touch it. You don't have to change a thing for it to break. Upstream dependencies change. Certificates expire. API versions sunset. Software isn't a machine you build and walk away from; it's a garden you water or it dies. Sometimes far more spectacularly and expensively than you'd imagine.

The build is the cheap part. Most of what software costs, you spend after launch. Marketing. Distribution. Customer support. Security patching. Every feature you ship is a promise you now have to keep. Even shutting it down costs more than you expect - you have to migrate everyone off first.

Nothing in production is temporary. That "I'll ship it now and fix it later" decision will become the cornerstone of the house of cards. You can change it fast with a coding agent later, sure - and break 99 other things, and lose your night. Thoughtful architecture goes a long way.

Nobody Understands the Whole System

Nobody understands the whole system. You'll have many users, with many needs, so you'll build many features. Some will be "temporary." "Experimental." "Just this once." In time you won't remember why a thing exists, what it connects to, or why it works that way. Write documentation, because you-in-five-years will be very frustrated with you-right-now. This compounds with every additional person touching the codebase.

Legacy code is a term of contempt for software successful enough to still be running. Languages most people under 60 have never heard of are clearing your paycheck this weekend. You'll depend on things you can't live without, written in ways you can't stand. Embrace it. Legacy code isn't going anywhere.

Most of your product is other people's code. In 2016, a trademark complaint over a package name led a developer to delete eleven lines of code, and all kinds of software broke across the internet. Every problem in every package you depend on is now your problem. Every vulnerability in them is now yours. If you're handling sensitive data - and almost all customer data is sensitive - this should keep you up at night.

The Ground Moves, and You'll Pay for It

The ground moves, and you'll pay for it. Every few years the industry changes its mind about the right way to build things. Sometimes it's a genuinely better idea. More often it's money - interest rates move, or investors want a different revenue shape, and suddenly everyone's product has to work a different way. You can get everything 100% right today and you'll still have to rebuild it in 3-5 years anyway. Conserve enough cash for your inevitable rebuild or be prepared to sunset when the pendulum swings.

What actually holds: Copyright is automatic on your code. Trademark your name; that one's worth the $350. Trade secrets are free and last forever, so don't publish your edge. Get IP assignment agreements signed by every contractor and cofounder - more deals get complicated by a missing assignment than by anyone getting copied.

AI collapsed the cost of creating software. It did nothing to the cost of owning it.

Your moat is distribution, the data you accumulate, and the fact that when something breaks at 11pm, somebody picks up.

Those compound. Code only decays.

Welcome to software.

Terminus documents are the small set of source-of-truth artifacts that agents read to generate everything else. If something in these documents is wrong, everything your agents produce will be wrong.

Each of our terminus documents has an assigned code owner, and no one can make changes to those documents without the code owner's PR approval.

If your agents produce something that doesn't look right, it can almost always be traced to a terminus document. It is best practice to update the terminus document rather than manually changing the output of your agents. This improves the system for the entire team, keeps everything in alignment, and prevents future mistakes.

Here is a look at some of the terminus documents that our agentic system is built upon:

Market Intelligence

positioning-architecture.mdx: Core story, vision/mission, value pillars, and why-now narrative — the root everything aligns to.

messaging-framework.mdx: Message hierarchy (top-line → pillars → proof points) that operationalizes positioning.

ideal-customer-profile.mdx: Validated ICP grounded in firmographics and pain-point prioritization.

market-segmentation.mdx: Segment definitions, scoring criteria, and GTM filter logic.

buyer-personas.mdx: User and buyer persona profiles mapped to value pillars.

competitive-landscape.mdx: Competitive synthesis vs. Pinecone, Weaviate, Qdrant, Milvus, Chroma, and pgvector.

Brand

brand-voice-tone.mdx: Canonical writing rules — urgently pragmatic, blunt, declarative, no hedging.

voice-eval/rubric.mdx: 7-dimension pass/fail rubric for grading external copy.

voice-eval/golden-set.yaml: Human-labeled calibration cases for the voice grader.

Commercial

sales-playbook.mdx: Discovery framework, objection handling, and competitive traps.

deal-qualification.mdx: Qualification criteria, gating questions, and disqualifier rules.

pricing-architecture.mdx: Pricing model, tiers, and packaging. (Load-bearing: changes require a decision-log entry).

icp-filter-criteria.yaml: Machine-readable ICP filters used by the autonomous crawler agent.

suppression-schema.yaml: Suppression list schema. (Don't cold email if the company is the wrong size, the person has the wrong job title, direct competitors, EU prospects, etc.)

Marketing

claims-vetted.md: Canonical vetted claims with sources — all marketing copy must cite from here.

competitors.md: Competitor reference snapshot (updated monthly).

format-rules.md: Markdown and citation rules for content-ops artifacts.

taxonomy.md: Shared terminology across marketing deliverables.

Product & Technical

product-positioning-brief.mdx: The bridge: how product capabilities map to positioning.

technical-differentiators.mdx: What makes our products technically distinct

feature-buckets.mdx: Top-level taxonomy for roadmap epics — auto-tagged in every spec and ADR.

tablestakes.mdx: The "good enough to displace top competitors" threshold by feature bucket.

roadmap.mdx: Canonical milestone view (detailed scope lives on GitHub).

Operational

decision-log/: Chronological rationale files for every load-bearing change. Required on substantive edits to any terminus doc.

automation-overview.mdx: All GitHub Actions workflows: schedules, secrets, inputs, and outputs.

agent-ownership.md: Every agentic automation across repositories: cadence, owner, consumer, and state.

Engineering

architecture-decisions/: Significant technical choices (ADRs) with context, decision, alternatives, and consequences.

specs/mission.md: Engineering mission and foundational design principles.

specs/tech-stack.md: Canonical tech stack decision and rationale.

development/repos.md: All repositories and their specific purposes.

development/branching-strategy.md: Git branching model and PR workflow.

Team Culture

code-review.md: Review process, routing rules, and mode-tag scrutiny requirements.

coding-agents.md: Mode-tag framework (mode:requires-expertise, mode:claude-led, etc.) gating review depth.

definition-of-ready.md & definition-of-done.md: Acceptance gates for work entry and completion.

qa-philosophy.md: Quality approach and testing strategy.

The Golden Rule

Any substantive change to a load-bearing terminus doc (positioning, pricing, ICP, code-review rules) requires a new entry in the operational decision log. Downstream artifacts — drafts, specs, battlecards, PRs — read from these; they do not feed back into them.

Establishing a rigorous set of terminus documents is the bedrock of any successful agent-driven workflow. By defining a single, unbreakable source of truth, you eliminate drift and ensure every output- from engineering specs to marketing copy- stays perfectly aligned with your core strategy.

Now, I'd love to hear from you: What are the foundational "terminus documents" your team relies on to keep your workflows and agents on track? Drop your must-have artifacts in the comments.

In my 20-year career planning and executing corporate transformations, I have never seen a shift so overwhelmingly thorough and complete in such a short period of time.

In just one year, we went from zero AI agents to a fully agent-driven organization.

This wasn't just a superficial tooling update. It required becoming deeply, intimately familiar with the company, product, and codebase. It meant creating documented context for all of it from scratch, architecting new technologies, training teams, and rebuilding roadmaps.

The most surprising part has been the shift in my own day-to-day. My working hours used to be consumed by planning and execution. Now, my time is spent on team member education, account provisioning, scoping permissions, and PR reviews. The execution is handled by the swarm.

The AI Maturity Curve

We didn't get here overnight. If you are charting your own organization's path, this is the exact maturity progression we experienced:

Tab Complete ➔ Agent IDE ➔ Context Engineering ➔ Compound Engineering ➔ MCP & Skills ➔ Harness Engineering ➔ Background Agents ➔ Autonomous Agent Teams

As we reached those final stages, the nature of "work" fundamentally changed. Here is what is now handled entirely by agents rather than human employees across our organization:

Engineering & Development

Investigate production incidents and perform root-cause analysis

Review pull requests (assess risk levels and escalate only when needed)

Write and contribute code at scale (nearly 3× output per engineer)

Automate long-stalled migrations (e.g., CSS system, product localization)

Maintain and fix flaky tests

Debug complex/hard-to-solve bugs

Continuously improve the product itself (analyze user feedback → propose improvements → validate via benchmarks and A/B tests)

Operations & Infrastructure

Triage alerts and production incidents

Run automated penetration testing / security vulnerability discovery

Run automated IT asset inventory

Orchestrate swarms of agents for parallel, verifiable tasks ("loop engineering")

Knowledge & Internal Support

Answer employee questions by combining knowledge bases + live codebase state

Enable non-engineers to fix copy, documentation, or product details without waiting on engineering

Data & Business Intelligence

Answer business intelligence questions via a semantic layer over the data warehouse

Generate charts and presentations from live data

Perform complex launch analysis (joining events, customer data platform, and subscription states)

Author quarterly progress reports and investor letters against OKR's and KPI's

Sales

Find and enrich product-qualified leads using internal knowledge

Author and execute outbound sequences

Prepare for customer conversations (value received, active projects, credit usage vs. contract)

Auto-generate branded, account-specific slide decks

Marketing

Draft product specs from scratch using conversations and documents across engineering/product

Align ICPs and personas to real time feedback from prospect and customer conversations

Align messaging house to positioning architecture and customer journey

Monitor and remediate gaps in AEO, SEO, and GEO

Author and maintain the full content pipeline (blogs, tutorials, how-to guides, explanations, references)

Support / Customer Success

Investigate support tickets and follow standard playbooks

Draft responses in the company's standard voice or escalate to engineering with a summary

Close hard (human-escalated) tickets significantly faster

Meta / Organizational

Replace or outperform expensive external SaaS tools with superior internal agent-built alternatives

Spread agent usage organically across every function via simple interfaces (e.g., Slack)

The Real Challenge Isn't Technical

Because we've built solid internal, agent-driven tools, we are now routinely replacing expensive external SaaS platforms. And through simple interfaces like Slack, agent usage has spread organically across every single function.

None of this is complicated to do.

The technology is ready. The barrier to entry is entirely organizational. To achieve a transformation of this speed and magnitude, you absolutely must have three things:

Unwavering executive sponsorship.

Director-level ownership to drive the integration.

Dedicated, continuous maintenance of your systems and context.

The agentic enterprise isn't a future roadmap item. It's already here. If you aren't building the infrastructure for it yet, let's talk.

A few weeks ago, I wrote about cognitive light cones and why great engineering managers operate as filters, not conduits. A few folks asked, "Does this filter run the other direction?"

It absolutely does, and understanding how it applies is crucial to your longevity and effectiveness as a leader.

The Filter Has Two Edges

When you're filtering for your team, you're managing inflow. You decide what goals land in their awareness based on whether they have the action range to do anything about it. If a goal is too big for their position, you absorb it, carry it, and translate it into something that fits their actual leverage.

But as you move up from lead to director, director to VP, and into the rooms where the biggest decisions live... a different filtering problem emerges.

It's no longer just about what you know. It's about what you're named responsible for.

The higher you climb in a large organization, the more critical it becomes to understand a foundational rule of organizational physics: Authority is a wonderful tool to drive impact, but direct responsibility must be managed with care.

This isn't about being cynical or dodging responsibility. It's about learning how large companies are actually engineered so you can navigate them safely, sustainably, and successfully.

Pay Attention

Large corporations are engineered, deliberately, to diffuse individual liability downward while concentrating high-level decision-making authority upward.

Boards set direction, but they don't execute. Corporate officers hold deep fiduciary duties, but those duties are bounded by the Business Judgment Rule—a legal doctrine that beautifully protects executives from personal liability for good-faith decisions, even when things go wrong. General counsels spend entire careers constructing and maintaining this structural separation.

The further you are from daily implementation, the more the organization protects you as an individual. That distance isn't a side effect of seniority—it's a conscious design feature.

When a data breach happens, the CISO gets deposed. When a product harms a consumer, the VP of Engineering gets subpoenaed. The CEO gives a deposition; the board issues a statement. But financial exposure naturally flows to the entity, not the individual.

This might lead you to believe that leaders are safe from the consequences the business might face in the event that something goes wrong. However, "piercing the corporate veil" is a legal decision where courts set aside a corporation's protection, allowing plaintiffs or creditors to hold directors personally liable for the corporation's debts, acts, or legal obligations. Courts grant veil-piercing in roughly 27–40% of litigated US/EU cases nationally, and over 50% in China. Most veil-piercing protection is lost not through malice, but through sloppiness.

Strategic Compensation

You can see this exact same filtering dynamic in executive compensation architecture: heavy equity, deferred comp, indemnification clauses, and D&O (Directors and Officers) insurance.

These aren't just fancy perks. They are the organization explicitly pricing in the risks of seniority and engineering structures to limit personal downside while preserving strategic control. The organization is actually filtering for its senior leaders, whether those leaders realize it or not.

Think about how your ownership shifts at each stage:

IC level: You own outputs.
Director level: You own budgets.
VP level: You own P&L.
C-suite level: You own narrative.

Each transition naturally widens the gap between what you control and what you're personally responsible for. To ascend smoothly, you need to manage that gap deliberately instead of stumbling into it.

Authority AND Responsibility? Just Say No

Most dedicated, capable mid-level leaders plateau not because they lack competence, but because they never stop collecting tasks to prove their worth.

Early on, taking absolute, clear ownership is exactly the right move! From IC to director, you earn trust by being the person who raises their hand and says, "I've got this. Hold me responsible." You demonstrate that you can carry the goal, the timeline, and the outcome.

But somewhere around the transition to VP or SVP, the rules of the game change.

The leaders who stall are often the ones who became too valuable operationally—the single throat to choke, indispensable in execution, but permanently capped in their strategic trajectory. They kept absorbing accountability the way a conduit manager keeps forwarding bad news: reflexively, in the name of ownership, without asking whether that goal is the right size for where they're standing now.

The leaders who move up successfully start filtering their own exposure with the same care they give their teams:

They build bench strength: They delegate true ownership, not just tasks. They empower someone else to be directly responsible—not to dodge work, but to grow their people and create appropriate structural distance.

They operate through governance: They guide outcomes using frameworks, steering committees, and approved recommendations rather than trying to micromanage production deliverables.

They hold veto power without holding delivery timelines: They maintain high influence over the final outcome, without tying their personal name to a rigid deadline.

They recognize what they sign: They understand that at senior levels, an email authorization or an org-chart sign-off carries real legal weight. They communicate through healthy organizational structures, not paper trails.

Plan For The Unforeseen Deposition

When we protect our teams, the underlying principle is simple: the goals people carry should match the action range they actually have. Mismatching that—giving them all the visibility but none of the power—creates the painful feeling of being a witness to a fire you aren't allowed to put out.

The inversion is just as true for you.

Taking on massive, named responsibility without the corresponding structural protection or executive authority isn't just stressful—it risks your professional well-being. It is the executive equivalent of a founder handing a complex runway model to an IC engineer and asking her to carry the weight of it.

She can hold it in her mind. She just shouldn't have to carry it on her shoulders.

The cognitive light cone isn't just a tool for protecting your engineers from goals that are the wrong size for their position. It's the map of your own career.

As you grow, your authority should expand so you can do more good for your organization. But your responsibility and exposure—what bears your name, what you've signed, and what attaches to you personally—should be managed with the exact same intentionality you bring to filtering for your team.

The leaders who thrive build both deliberately, in parallel. Learning this balance doesn't make you less of a leader; it makes you a sustainable, resilient, and highly effective one. You owe it to yourself—and to the teams you protect—to look after your own career path with that same level of care.

57 Days Ago, I Had No Idea What I Was Doing.

I'm currently a product manager. Not an engineer. Not a marketer. Not a content strategist or a data analyst or a sales ops person. I'm one person at a 10-person startup trying to figure out how to go-to-market from scratch.

So I just started.

The On-Ramp: The Foundation You Can't Skip

Before day one, there were a few hours where I set up the foundation. I want to be honest about this because I've watched too many people try to skip it — and I've watched them end up frustrated, stuck, or building in the wrong direction entirely.

Here's what actually needs to exist before any of this works:

Claude CLI: Not the browser chat. The command-line tool that runs inside your terminal, beside your actual files, with your actual work. This is the thing that lets Claude not just answer questions but do things — read files, write files, version control, run automations. If you're talking to Claude in a browser window and copy-pasting results into Notion, you're not building a system. You're doing more work.

GitHub and the gh CLI: Everything lives in a GitHub repository. Not in Obsidian. Not in Notion. Not in a folder on your desktop. A git repo. This sounds scary if you've never used one, but here's all you need to know: it's a folder where everything has a history, everything is searchable, and both you and Claude can read it, write to it, and automate against it. Obsidian is great for notes. It's the wrong foundation for a team system that does things.

Structured Claude.md's plus a few hooks and rules: Small configuration files that tell Claude how to behave in your specific context. What to always do. What to never do. Where things live. How to format output. This is what makes Claude feel like your assistant rather than a generic one — and it's what makes the system get smarter over time instead of starting from scratch every session.

That's it. Three things. It takes two hours max if you're on a clean machine.

I know it sounds like setup cost. It is. But it's the only setup cost there is — after this, everything compounds.

A quick note: For anyone who's heard me say "just call me if you need help getting started" — I mean it. I've gotten dozens of people through this on-ramp in the last few months and every single one of them was off and running within two hours. The first session is the hardest. After that, you'll wonder what took you so long.

Days 1 & 2: The Power of the First Question

Day 1: I asked Claude to research our competitors.

That's it. Nothing fancy. I had a doc, Claude had the internet, and we filled it in together — who they were, what they offered, how they positioned themselves, what they charged.

One thing jumped out immediately: a capability gap. Something our product did that none of theirs did. That single finding — confirmed in about two hours on the first day — became the foundation of everything. Every piece of content. Every sales pitch. Every product decision. I didn't plan for that. I just started, and the problem revealed itself.

Day 2: I had a new problem.

Now that I knew what we had, I needed to make sure we could find out when that changed. What if a competitor closed that gap next month? I'd want to know immediately.

So Claude and I built a small automation. Every month, it checks competitor websites, reads their docs, and flags anything new. It opens a pull request with what changed. I review it. Done. That took maybe three hours.

Then I thought: what else changes in our market that I should be tracking? So we built another automation to monitor that too — pulling from sources I'd never have time to check manually, surfacing only what was relevant.

I didn't know I needed either of those things when I woke up that morning. The day before's work revealed them.

How It Actually Goes (The Compound Effect)

You don't start with a plan for an 18-workflow automated system. You start with one question. The answer to that question reveals the next question. And slowly, almost without noticing, you've built something real.

By Day 5: We had automated competitor monitoring, a content gap tracker, a market intelligence feed, and a CRM integration that turned sales call recordings into engineering tickets.

By Day 14: We had a brand system, a pitch deck framework, a 12-cohort customer research map, and account dossiers for our most important customer relationships.

By Day 41: We had a weekly intelligence digest that landed in Slack every Friday — competitive signals, regulatory news, market updates, conference opportunities — synthesized from eight different data sources, automatically.

By Day 57: We had 18 scheduled automations, a full outbound sales sequence for every customer segment, a blog content pipeline, and an automated image generator.

I did not know on day one that any of that was possible. I just knew what question I needed to answer that day.

What This Is (And Isn't)

What this is NOT:

A story about being technical: I did not write the code. I did not set up a server. The automations are workflows — Claude wrote them. I described what I wanted in plain English and we figured it out together.

A story about having a strategy: I didn't have a strategy on day one. I had a competitor doc and a question.

A story about scale: We're 10 people. My Claude Teams plan and I are the entire GTM function. There is no agency, no budget for a full marketing stack, no RevOps team.

What it IS a story about:

It's about the fact that the gap between "I have no idea what I'm doing" and "I have a system that compounds" is smaller than you think — and the bridge is just starting.

If you're an engineer who's never thought about marketing: you already know how to break a problem into smaller pieces. That's the whole skill.

If you're a marketer who's never touched code: you don't need to touch code. You need to describe what you want. Claude handles the rest.

If you're early in your career and wondering how people build these things: they build them one day at a time, surprised by the next problem, and then solve that one too.

If you're later in your career and wondering if you have the chops for this new world: the new world rewards people who can identify problems and communicate clearly. You've been doing that for years.

The Real Secret: Don't Stop

The system I have now has taken 57 days to build.

Not 57 full days. 57 calendar days, where most of the time I was doing my actual job — running sprints, talking to customers, writing specs, sitting in meetings. The GTM system got built in the margins. An hour here, an afternoon there.

The thing that made it compound wasn't intelligence or experience or a plan.

It was just not stopping.

Every day I'd look at what we'd built the day before, notice one thing that was missing or broken, and fix it. Claude and I would solve it together. Then I'd stop and do my job. The next day, same thing.

By day 57, I looked back and couldn't believe what we'd built.

Your First Step

If you want to start, start with the on-ramp. Two hours. Claude CLI, a GitHub repo, a few configuration files. If you're not sure how, reach out — I'll walk you through it. I've done it enough times now that I can get anyone set up in a single call.

Then ask your first question. Not a big strategic question. Just: What's one thing I need to know right now?

See what the answer reveals. Come back tomorrow.

That's the whole playbook.