Tag: AI Operations

  • Four-Layer Data Architecture: Behavior-First Strategy

    Four-Layer Data Architecture: Behavior-First Strategy

    Tygart Media Strategy
    Volume Ⅰ · Issue 04Quarterly Position
    By Will Tygart
    • Long-form Position
    • Practitioner-grade

    The instinct, when building a complex operation, is to find one tool that can hold everything. One source of truth. One dashboard. One system of record for all data types.

    This instinct is wrong, and it produces exactly the kind of system it’s trying to avoid: a single tool that does everything poorly, a migration project that costs more than the original implementation, and a team that has learned to distrust the data because the tool was never designed for the behaviors it was forced to support.

    The behavior-first alternative for data architecture doesn’t start with “what tool can hold everything.” It starts with: what are the distinct behaviors this data needs to support, and which tool is genuinely best suited for each one?

    The Four Data Behaviors

    In a multi-site AI-native content operation, four distinct data behaviors emerge:

    Machine-generated operational data needs to be written and read by automated systems at high speed. Batch job results, embedding vectors, image processing logs, Cloud Run execution histories. No human looks at this data directly. It needs to be fast, cheap, and structured for programmatic access. GCP serves this behavior — Firestore for structured operational state, Cloud Storage for large artifacts, BigQuery for analytical queries across the full dataset.

    Human-actionable signals need to be displayed clearly enough that a person can take action without wading through noise. Site health alerts, content gaps, client status changes, task assignments. This data needs to be readable, filterable, and connected to the people who need to act on it. Notion serves this behavior — not because it’s the most powerful database, but because it’s the most human-readable one, with views that can surface exactly the signal each role needs.

    Published content needs to be delivered to web visitors and search engines at performance standards those audiences require. WordPress serves this behavior. It was designed for it. The mistake is asking WordPress to also serve as the storage layer for unpublished content, the analytics layer for content performance, or the task management layer for content production. It wasn’t designed for those behaviors and it’s not good at them.

    Files and documents need to be stored, versioned, and shared across tools and collaborators. Google Drive serves this behavior. Skills, SOPs, brand guidelines, exported data — anything that exists as a file rather than as structured data belongs in Drive, not in a database trying to handle file attachments as a secondary feature.

    Why Separation Produces Better Systems

    A four-layer architecture feels like more complexity than a single-tool approach. In practice it produces less complexity, because each tool is operating within its design constraints instead of being stretched beyond them.

    The signal-to-noise problem in most dashboards comes from forcing machine-generated data and human-actionable signals into the same view. The machine data overwhelms the human signals. The solution is usually “better filtering” — which is the wrong answer. The right answer is storing machine data where machines can read it and surfacing human signals where humans can act on them.

    The performance problem in most content operations comes from asking WordPress to be a content management system when it’s a content delivery system. The content that belongs in a CMS — drafts, revisions, briefs, research notes — should be in Notion. The content that belongs in a CDS — published articles, page templates, media files — should be in WordPress. When you separate these, both tools perform their actual function better.

    The data loss problem in most operations comes from treating the most convenient tool as the system of record. When content lives only in WordPress, a site failure is a data failure. When operational state lives only in a Cloud Run service, a deployment change is a state failure. The four-layer architecture ensures that each data type has a permanent home in the tool designed to hold it — and that the tools interact through APIs rather than through manual migration.

    Behavior-First System Design — Knowledge Cluster

    Related: CRM Community Framework for Restoration Companies — the live proof of concept for behavior-first system design.

  • ADHD AI-Native Operations: Behavior-First System Design

    ADHD AI-Native Operations: Behavior-First System Design

    Tygart Media Strategy
    Volume Ⅰ · Issue 04Quarterly Position
    By Will Tygart
    • Long-form Position
    • Practitioner-grade

    The conventional wisdom about ADHD and work is built around a simple premise: the ADHD brain is deficient in the behaviors that work requires, and management strategies exist to compensate for those deficiencies. More structure. Better schedules. Accountability systems. Tools designed to impose the consistency the brain doesn’t generate naturally.

    This is tool-first thinking applied to a human brain. And like most tool-first thinking, it produces systems that fight the behavior instead of serving it.

    The behavior-first alternative asks a different question: what does the ADHD brain actually do, at its best, and what system design would allow it to do more of that?

    What the ADHD Brain Actually Does

    Three behaviors characterize high-functioning ADHD cognition when the environment supports them:

    Hyperfocus. Sustained, intense concentration that arrives unbidden and runs at extraordinary depth for an unpredictable duration. Not concentration on demand — concentration that seizes the operator when a problem activates the interest system. The output of a hyperfocus session is disproportionate to the time invested, and the quality often exceeds what deliberate, scheduled work produces.

    Interest-based attention routing. The ADHD attention system allocates based on interest, novelty, urgency, or challenge — not importance. High-interest work gets exceptional focus. Low-interest work gets almost none. This is not a failure of will. It’s a feature of a different attentional architecture.

    Cross-domain pattern recognition. Rapid context-switching, which looks like distractibility in sequential-task environments, produces something valuable in environments that reward synthesis: the ability to connect observations across unrelated domains and identify patterns that single-domain experts miss.

    The System That Serves These Behaviors

    An AI-native operation designed around these behaviors looks different from a conventional productivity system:

    For hyperfocus: The system captures whatever the hyperfocus session produces — immediately, in full, without requiring the operator to organize it mid-session. The Second Brain stores the output. The cockpit session for the next day picks up the thread. The non-linearity of hyperfocus (jumping between connected insights, building in spirals) becomes productive because the AI can hold the full context of the spiral across sessions.

    For interest-based attention: Low-interest, deterministic work routes to automated pipelines. Haiku runs taxonomy fixes at scale. Cloud Run handles scheduled publishing. Batch jobs process a hundred posts while the operator is doing something that has activated their interest system. The attention that would have been coerced onto low-interest work is freed for the high-interest work where ADHD attention genuinely excels.

    For pattern recognition: The cross-domain synthesis that ADHD cognition produces naturally — connecting a restoration industry CRM insight to an AI architecture principle to a neurodiversity research finding — is exactly what generates the novel frameworks that constitute a knowledge operation’s core asset. This isn’t compensated for. It’s the product.

    The Architecture Principle

    The systems that emerged from designing around ADHD constraints are not ADHD-specific. They are better systems. External working memory (the Second Brain) outperforms internal working memory for complex multi-client operations regardless of neurology. Routing low-value-attention work to automation is better for any operator. Pre-staged context reduces friction for everyone.

    The ADHD constraints forced designs that a neurotypical operator would also benefit from — because the constraints that neurodivergence makes extreme are present in milder form in everyone. The behavior-first design process, applied to an ADHD brain, produced infrastructure. The same process, applied to any operation, produces the same result: systems that serve the actual behavior, compound over time, and don’t require the operator to fight their own cognition to function.

    Behavior-First System Design — Knowledge Cluster

    Related: CRM Community Framework for Restoration Companies — the live proof of concept for behavior-first system design.

  • AI Work Order Architecture: Decoupling AI & Execution

    AI Work Order Architecture: Decoupling AI & Execution

    Tygart Media Strategy
    Volume Ⅰ · Issue 04Quarterly Position
    By Will Tygart
    • Long-form Position
    • Practitioner-grade

    AI systems are good at identifying problems. Automated systems are good at fixing them. The failure mode that kills most AI automation projects is building them as one thing instead of two.

    When you couple intelligence and execution in a single system, you get something that can do everything slowly and nothing reliably. The intelligence layer needs to be conversational, contextual, and judgment-driven. The execution layer needs to be deterministic, fast, and parallelizable. These are fundamentally different behaviors, and they require different tools.

    The Work Order as the Bridge

    The behavior-first design for AI automation has three distinct stages: identify (Claude analyzes a system and surfaces what needs to be done), deposit (Claude writes a structured work order to a persistent queue), and execute (a Cloud Run worker reads the work order and runs the fix).

    The work order is the key artifact. It’s the contract between the intelligence layer and the execution layer. A well-formed work order contains everything the execution layer needs to run without asking Claude any follow-up questions: the target (site, post ID, endpoint), the operation (what to do), the parameters (how to do it), and the success criteria (how to know it worked).

    When the work order is well-formed, the execution layer is a dumb runner. It doesn’t need to understand context, history, or judgment. It reads the work order, executes the operation, and writes the result back. The intelligence that produced the work order stays in the intelligence layer — which is exactly where it belongs.

    What This Looks Like in Practice

    In a multi-site content operation, Claude might analyze a WordPress site and identify 47 posts with missing FAQ schema. The tool-first approach runs Claude in a loop, generating and publishing schema for each post sequentially. This is slow, context-dependent, and fragile — if Claude loses context mid-run, the job is incomplete and the state is unclear.

    The behavior-first approach: Claude generates 47 structured work orders, one per post, and deposits them in a Notion database with status “Queued.” A Cloud Run service reads the queue and processes each work order independently, in parallel, writing results back to each row. Claude is done in minutes. The Cloud Run service finishes the execution while Claude is doing something else entirely.

    The behaviors are clean. The tools serve them. The system scales horizontally without requiring Claude to be in the loop for execution.

    The Two Lanes of AI Automation

    Not everything belongs in the work order queue. Some operations require judgment that the execution layer can’t replicate: content quality assessment, strategy decisions, anything where “it depends” is the correct first answer. These belong in a different lane — one where Claude stays in the loop through completion.

    A mature AI automation architecture has both lanes clearly defined. Deterministic operations (taxonomy fixes, schema injection, meta rewrites, image uploads, internal link additions) go to the work order queue and run without Claude. Judgment-dependent operations (content strategy, quality review, client recommendations) stay in the conversational layer where Claude’s judgment can be applied continuously.

    The discipline is in knowing which lane each operation belongs in — and resisting the temptation to put judgment-dependent work in the queue just because it would be faster. Faster execution of the wrong thing is not an improvement.

    Behavior-First System Design — Knowledge Cluster

    Related: CRM Community Framework for Restoration Companies — the live proof of concept for behavior-first system design.

  • Tacit Knowledge Extraction: Behavior Before AI Systems

    Tacit Knowledge Extraction: Behavior Before AI Systems

    Tygart Media Strategy
    Volume Ⅰ · Issue 04Quarterly Position
    By Will Tygart
    • Long-form Position
    • Practitioner-grade

    Every organization has two kinds of knowledge. The first kind is documented: processes, policies, training materials, SOPs. The second kind is tacit: the adjustments people make without thinking, the thresholds they’ve learned from experience, the judgment calls they can execute in seconds but couldn’t explain in a meeting.

    The documented knowledge is easy to feed into an AI system. The tacit knowledge is what makes the organization actually work — and it’s almost never in a format that AI can use.

    The gap between these two knowledge types is where most enterprise AI implementations fail. Companies feed their AI the documentation and wonder why it can’t give the same answers a 10-year veteran would give. The answer is that the 10-year veteran isn’t running on the documentation. They’re running on the tacit layer — and nobody captured it.

    What Tacit Knowledge Extraction Actually Requires

    You cannot extract tacit knowledge through forms, surveys, or documentation requests. Tacit knowledge by definition is knowledge that the holder cannot fully articulate without a skilled interviewer pulling it out. The behavior that surfaces it is specific: a conversational sequence that descends through four distinct layers.

    Layer 1 — Surface protocol: “What’s your process when X happens?” This gets the documented version — what people think they do, what they’d write in an SOP. Necessary baseline but not the target.

    Layer 2 — Exception probing: “When do you deviate from that?” This surfaces the adaptive layer — the judgment calls that experience produces. The deviations are where tacit knowledge lives.

    Layer 3 — Sensory and somatic: “How do you know it’s that specific problem and not something else?” This is the hardest layer to surface and the most valuable. It captures knowledge that the holder has never verbalized — pattern recognition so ingrained it operates below conscious awareness.

    Layer 4 — Counterfactual pressure: “What would break if you weren’t here tomorrow?” This surfaces the knowledge hierarchy — what actually matters versus what’s ritual. Most organizations don’t know which is which until the person with the knowledge leaves.

    The Behavior Determines the Tool Stack

    Once this extraction behavior is understood, the tool selection for the AI system becomes clear. You need: a way to capture the conversation at high fidelity, a way to convert the transcript into structured knowledge artifacts, a storage layer that preserves the knowledge in a format AI systems can query, and an embedding layer that makes the knowledge semantically searchable.

    These are four distinct behaviors served by four distinct tools. The extraction conversation is a human behavior — no tool replaces it. The structuring is where AI earns its keep: running the transcript through multiple models with different attack angles, identifying the tacit signatures embedded in the language, organizing the output into the knowledge concentrate schema. The storage is a database decision. The embedding layer is a vector store.

    None of these tool choices could have been made intelligently without first understanding the extraction behavior. The behavior is the constraint that makes the tool selection tractable.

    The Minimum Viable Experiment

    For any organization that wants to capture its tacit knowledge layer before it walks out the door: four extraction conversations, transcribed and run through a three-model distillation round, produce a knowledge artifact dense enough to answer questions that the documentation cannot. The experiment takes a week and costs almost nothing. The cost of not doing it shows up when the person who holds the knowledge leaves and the organization discovers, for the first time, how much was never written down.

    Behavior-First System Design — Knowledge Cluster

    Related: CRM Community Framework for Restoration Companies — the live proof of concept for behavior-first system design.

  • Behavior-First System Design: Build for Action, Not Tools

    Behavior-First System Design: Build for Action, Not Tools

    Tygart Media Strategy
    Volume Ⅰ · Issue 04Quarterly Position
    By Will Tygart
    • Long-form Position
    • Practitioner-grade

    There is a mistake that kills more technology projects than bad code, bad vendors, or bad timing combined. It happens before a single line is written, before a single subscription is purchased, before anyone even knows there’s a problem.

    The mistake is this: choosing the tool before understanding the behavior.

    It looks like a reasonable decision. You need to manage customer relationships, so you buy a CRM. You need to publish content, so you build around WordPress. You need to organize knowledge, so you set up Notion. The tool selection feels like the hard part — the research, the demos, the pricing comparisons. By the time you’ve chosen, you feel like the work is half done.

    It isn’t. You’ve just committed to building a system shaped like a tool instead of shaped like a behavior. And when the behavior and the tool don’t match, the system fails quietly — not in a crash, but in a slow drift toward abandonment, workarounds, and the quiet understanding that “we don’t really use that anymore.”

    The alternative is building the system around the behavior first. It sounds obvious. Almost nobody does it.

    What “Behavior-First” Actually Means

    A behavior is what actually happens — or needs to happen — in your operation. It’s not a goal, not a feature request, not a capability. It’s the specific sequence of actions, decisions, and handoffs that produce a result.

    Most system design starts with tools and works backward to behaviors. Behavior-first design starts with the behavior and works forward to the minimum set of tools that can serve it.

    The difference sounds subtle. The outcomes are not.

    When you start with the tool, you spend the first six months learning the tool’s shape and then trying to reshape your operation to fit it. When you start with the behavior, you spend the first six months building a system that serves the operation — and then choosing the simplest tool that delivers what the behavior requires.

    The tool-first approach produces complexity. The behavior-first approach produces leverage.

    Six Behaviors That Built This Operation

    The following examples are drawn from a single AI-native operation built over three years. None of them started with a tool selection. All of them started with the question: what actually needs to happen here?

    1. Write → Store → Distribute (The Content Pipeline)

    Most content operations are built around WordPress. The platform is the system. Articles go into WordPress, WordPress manages drafts, WordPress publishes, WordPress is the source of truth. This is tool-first design.

    The behavior is different. The behavior is: write a piece of content, preserve it permanently, distribute it to wherever it needs to go.

    When you build around that behavior, WordPress becomes one destination among several — not the system. Notion becomes the storage layer. WordPress becomes the distribution layer. The article exists independently of where it’s published. If WordPress goes down, if the WAF blocks you, if the site moves hosts — the content is not at risk. The behavior (write → store → distribute) is served by a stack of tools, none of which is the irreplaceable center.

    The practical result: every article written in this operation goes to Notion first, WordPress second. Not because Notion is a better publishing platform — it isn’t. Because the behavior requires permanent, accessible storage before distribution, and WordPress was never designed to be that.

    2. Identify → Deposit → Execute (The Work Order Architecture)

    The problem: an AI system can identify what’s wrong with a WordPress site in seconds — thin content, missing schema, broken taxonomy, orphan pages — but the identification and the fix are handled by completely different systems. The identification lives in a conversation. The fix lives in a deployment. There’s no bridge.

    The behavior is: Claude identifies a problem, deposits a structured work order, a Cloud Run worker executes it. The intelligence and the execution are decoupled. Neither layer needs to know how the other works.

    Built around that behavior, the tool choices become obvious. Notion holds the work order queue — not because Notion is a task management tool (though it is), but because Claude can write to it via API and a Cloud Run service can read from it. The tools serve the behavior. The behavior doesn’t contort to serve the tools.

    3. Extract → Distill → Deploy (The Human Distillery)

    The behavior here is one of the rarest in any knowledge-intensive industry: taking tacit knowledge — the unwritten, unspoken operational intelligence that lives in people’s heads — and converting it into structured artifacts that AI systems can immediately use.

    Tacit knowledge doesn’t fit into forms, surveys, or databases. It surfaces through conversation. The extraction behavior is a specific sequence: disarm the subject, descend through four layers of questioning (documented protocol → exception cases → sensory knowledge → counterfactual pressure), capture what surfaces, and distill it into a dense artifact.

    That behavior existed long before any tool was selected to support it. The tool choices — which models to run distillation through, how to structure the output schema, where to store the resulting knowledge concentrates — all came after the behavior was understood. The behavior is irreplaceable. The tools are interchangeable.

    4. Observe → Route → Produce (Task Routing for Variable Attention)

    Most productivity systems are built around the assumption that the operator applies consistent, scheduled attention to work. Tasks sit in queues. Work happens in order. Focus is managed through priority.

    That behavior doesn’t match how an ADHD-wired operator actually works. The actual behavior is: attention arrives unbidden, attaches to whatever has activated the interest system, runs at extraordinary intensity, and then ends — also unbidden. The work happens in spirals, not lines.

    An AI-native operation designed around this actual behavior routes tasks differently. High-interest, high-judgment work goes to the operator when the operator’s attention is activated. Low-interest, deterministic work gets routed to automated pipelines that run on schedule regardless of operator state. The behavior — variable, interest-driven, high-intensity — shapes the system. The system doesn’t demand behavior the operator can’t deliver.

    The result is not a workaround. It’s an architecture. And the architecture works better for a neurotypical operator too — because the constraints that neurodivergence makes extreme are present in milder form in everyone.

    5. Touch → Remind → Refer (The CRM Community Framework)

    The restoration industry spends $150–$500 per lead acquiring customers and then never contacts them again. Not because they don’t want to. Because the tool they have — a job management system built around transactions — doesn’t support the behavior they need.

    The behavior is: make consistent, relevant, human contact with warm relationships at regular intervals, using legitimate business moments as the reason. That’s it. The behavior is simple. The tool selection is almost irrelevant — a spreadsheet and a Mailchimp free account can execute it. What matters is that the system is built around the behavior (stay present in warm relationships) rather than around the tool (send marketing emails).

    When you build around the tool, you get a marketing email campaign. When you build around the behavior, you get a community — a network of people who feel a genuine two-way relationship with your company and who refer you business because you’re the company that actually stayed in touch.

    The technical implementation of this — segmentation from ServiceTitan and Jobber, email automation in Mailchimp or Brevo, relationship intelligence in a Notion Second Brain — is documented in full in the CRM Community Framework series. Every tool choice in that series is downstream of the behavior. None of it works if you start with the tool.

    6. Signal → Display → Act (The Four-Layer Data Architecture)

    A complex multi-site operation generates data from dozens of sources simultaneously — WordPress post metrics, GCP Cloud Run logs, Notion task statuses, client pipeline movements, content performance signals. The instinct is to find one tool that can hold all of it. The tool becomes the system.

    The behavior is different for each data type. Machine-generated operational data (image processing logs, batch job results, embedding vectors) needs to be written and read by automated systems at high speed. Human-actionable signals (site health alerts, content gaps, client status changes) need to be displayed in a way a person can act on without noise. Content in progress needs to be stored independently of where it will ultimately be published.

    Four behaviors. Four tool layers. WordPress for published content, GCP for machine data, Notion for human signals, Google Drive for files. No single tool tries to do all four. Each tool is chosen because it’s the best fit for one specific behavior — not because it can technically handle the others.

    How to Apply This in Your Operation

    The behavior-first design process has three steps, and none of them involve opening a browser tab to research tools.

    Step 1: Write down what actually needs to happen. Not what you want to accomplish. Not what you wish the system could do. The specific sequence of actions that produces the result you need. Subject → verb → object, repeated until the behavior is fully described. “Someone writes an article. The article needs to be findable in six months. The article needs to be published to a website.” That’s a behavior. “We need better content management” is not.

    Step 2: Identify where the behavior breaks down today. Every system has the places where it works and the places where it silently fails. A CRM that nobody updates after the job closes. An email platform that has contacts from three years ago and no segmentation. A content process that lives in someone’s head. These are the behavior gaps — the places where the actual behavior doesn’t match the intended behavior.

    Step 3: Choose the simplest tool that serves the behavior. Not the most powerful. Not the most popular. Not the one with the best demo. The one that makes the behavior easiest to execute consistently. A $13/month Mailchimp account and a Google Sheet will outperform a $400/month marketing platform if the behavior is four emails per year to a warm local database — because the complexity of the expensive tool introduces friction that kills the behavior entirely.

    The AI-Native Operation Is Behavior-First by Definition

    The reason AI-native operations tend to outperform tool-native operations has nothing to do with AI being smarter. It has to do with design philosophy.

    AI tools, at their best, are infinitely flexible. They don’t impose a shape on your operation. They serve whatever behavior you describe. The operator who builds an AI-native operation is forced — by the nature of the tools — to understand their own behaviors first. You cannot prompt your way to a useful output without knowing what useful looks like. You cannot build a pipeline without understanding the sequence it’s meant to automate.

    This is why the AI-native operator has a structural advantage over the SaaS-native operator. Not because their tools are better. Because the process of building with AI forces behavior-first thinking, and behavior-first thinking produces systems that compound over time instead of decaying into expensive shelf-ware.

    The tool will change. The behavior won’t. Build the system around the behavior.

    Frequently Asked Questions

    How do you identify the behavior if you’ve always built around tools?

    Start with the breakdowns. Wherever your current system has workarounds, manual steps, or things people do “outside the system,” those are the places where the tool’s shape and the behavior don’t match. The workarounds are the behavior. Build the new system to serve them directly.

    Doesn’t this make tool selection harder and slower?

    It makes it faster. When you know the behavior precisely, you have a clear evaluation criterion: does this tool make the behavior easier to execute consistently, or does it add complexity? Most tool evaluations fail because the criteria are vague. Behavior-first evaluation is fast because the test is concrete.

    What if the behavior changes over time?

    Behaviors evolve. Systems built around behaviors can evolve with them — you swap the tool layer without disrupting the behavior layer. Systems built around tools can’t evolve without a full rebuild, because the tool is the system. Behavior-first architecture is inherently more resilient to change.

    Is this just another way of saying “process before technology”?

    It’s related but more specific. “Process before technology” is usually interpreted as documentation before implementation — write the SOPs, then build the tools to support them. Behavior-first design is about understanding the actual behavior of the operation, which often differs significantly from the documented process. You’re designing around what people and systems actually do, not what they’re supposed to do.

    How does this apply to AI tool selection specifically?

    AI tools are especially susceptible to tool-first thinking because they’re impressive in demos. The demo shows capability; the behavior question asks whether that capability serves a specific sequence in your operation. Most AI tool adoptions fail not because the tools are bad but because they were selected based on capabilities rather than behaviors. The question is never “what can this tool do?” It’s “which of my behaviors does this tool serve, and does it serve them better than what I have now?”

    Behavior-First System Design — Knowledge Cluster

    Related: CRM Community Framework for Restoration Companies — the live proof of concept for behavior-first system design.

  • How Claude Managed Agents Handles Idle Time (And Why It Matters for Your Bill)

    How Claude Managed Agents Handles Idle Time (And Why It Matters for Your Bill)

    Tygart Media Strategy
    Volume Ⅰ · Issue 04Quarterly Position
    By Will Tygart • Long-form Position • Practitioner-grade

    The most counterintuitive thing about Claude Managed Agents pricing is what you don’t pay for. Most people, when they hear “$0.08 per session-hour,” mentally model a virtual machine running continuously. That’s the wrong mental model. Here’s the right one, and why it matters for your bill.

    The Core Distinction: Active vs. Idle

    Three stacked layers: chat UI, tools, agent runtime
    The core distinction — active vs idle.

    Managed Agents session runtime only accrues while your session’s status is running. The session can exist — open, initialized, capable of continuing — without accumulating runtime charges when it’s not actively executing.

    The specific states that do not count toward your $0.08/hr charge:

    • Time spent waiting for your next message
    • Time waiting for a tool confirmation
    • Time waiting on an external API response your tool is calling
    • Rescheduling delays
    • Terminated session time

    This is a meaningful architectural decision by Anthropic. They’re billing on what actually taxes their compute — active execution — not on session existence or wall-clock time.

    Why This Is Different From How You Might Expect Billing to Work

    Compare three billing models:

    Virtual machine billing (what this is not): You pay for every hour the instance exists, whether it’s idle or saturated. A VM running 24/7 with 10% actual utilization still costs 24 hours/day.

    Lambda/function billing (closer analogy): AWS Lambda bills on execution duration and invocation count — you pay when code actually runs, not when a function is “available.” Idle Lambda functions cost nothing.

    Managed Agents billing (what this actually is): Closer to Lambda than VM. You pay $0.08 per hour of active execution. A session that runs for 2 hours of wall-clock time but has 90 minutes of waiting costs $0.08 × 1.5 hours = $0.12, not $0.08 × 2 hours = $0.16.

    A Real Scenario: The Human-in-the-Loop Agent

    Diagram comparing a long context window bar with a shorter output limit bar
    A real scenario — the human-in-the-loop agent.

    Consider an agent that processes your inbox for action items and waits for your approval before sending replies. Wall-clock time: 4 hours open during your workday. Actual active execution: 20 minutes of processing across that 4-hour window, with the rest spent waiting for your review decisions.

    • VM billing equivalent: 4 hours × rate = significant charge
    • Managed Agents billing: 20 minutes × $0.08/hr = $0.027

    The difference is real. For interaction-heavy agents where the agent frequently waits for human decisions, the idle-time exclusion significantly reduces costs versus a naive per-hour model.

    A Real Scenario: The Autonomous Batch Agent

    Now consider an agent running a fully autonomous content pipeline — no human checkpoints, just continuous execution through a queue. Wall-clock time and active execution time are nearly identical because the agent never waits.

    • A 2-hour autonomous batch: 2 hours × $0.08 = $0.16

    Here, the idle-time model provides no benefit — the agent has no idle time. The billing is effectively equivalent to per-hour pricing because execution is continuous.

    Code Execution Containers Are Included

    One more billing nuance worth knowing: when your agent runs code, the execution happens in sandboxed Linux containers. These containers are not separately billed on top of session runtime. The $0.08/hr covers both the session runtime and the container execution. This is explicitly documented by Anthropic and represents meaningful savings if your agent is doing significant code execution work — you’re not paying twice.

    What This Means for Workload Design

    Desk with laptop, checklist notebook, and billing card ready before creating an Anthropic API key
    What this means for workload design.

    If you’re designing agent workflows and have the choice between architectures, the billing model creates a useful signal:

    • Agents that wait on humans: Metered billing is favorable — you only pay for the actual reasoning and execution time, not the human decision time
    • Fully autonomous agents: Billing approaches equivalent to per-hour rates — optimize these on token efficiency, not idle reduction
    • Scheduled batch agents: Natural fit — run when needed, terminate when done, no idle accumulation

    The 24/7 Agent Math

    For anyone doing the 24/7 always-on calculation: the maximum theoretical runtime exposure is 24 hrs × $0.08 × 30 days = $57.60/month in session fees. But a 24/7 agent with zero idle time is rare in practice. Agents that sleep between triggers, wait on external data, or hold for human decisions have meaningful idle windows that reduce the actual charge below the theoretical ceiling.

    Full monthly cost analysis: The Real Monthly Cost of Running Claude Managed Agents 24/7. Pricing reference: Complete Pricing Guide. All questions: FAQ Hub.

    Related on Tygart Media: rate limits · managed agents review · Claude pricing.

  • Claude Managed Agents Rate Limits — What 60 Requests Per Minute Means in Practice

    Claude Managed Agents Rate Limits — What 60 Requests Per Minute Means in Practice

    The Lab · Tygart Media
    Experiment Nº 561 · Methodology Notes
    METHODS · OBSERVATIONS · RESULTS

    You’re planning to run Claude Managed Agents at scale. You’ve modeled the token costs, the session-hour charge, the workload cadence. Then you hit the actual constraint: rate limits. Here’s what 60 requests per minute actually means in practice, and whether it’s going to be your ceiling.

    The Two Limits You Need to Know

    Three stacked layers: chat UI, tools, agent runtime
    The two limits you need to know.

    Managed Agents has two endpoint-specific rate limits, separate from your standard Claude API limits:

    • Create endpoints: 60 requests per minute
    • Read endpoints: 600 requests per minute

    Your organization-level API limits apply on top of these. If your org is on a tier with a lower requests-per-minute ceiling, that’s the actual binding constraint.

    What “60 Create Requests Per Minute” Actually Means

    A create request, in Managed Agents context, is typically a session creation call — starting a new agent session. 60/minute means you can start 60 sessions per minute maximum. For almost all real workloads, this is not the binding constraint. Here’s why:

    Think about what generates create requests. If you’re running a batch pipeline that starts one new agent session per content item, processing 60 items per minute would saturate the limit. But a 60-item-per-minute content pipeline is running 3,600 items per hour — a genuinely high-volume operation. Most production agent workloads don’t look like this. They look like one session that runs for minutes or hours, processes multiple tasks within that session, and terminates when done.

    The create limit matters most for architectures where you’re spinning up a new session per task rather than running tasks within a persistent session. If that’s your pattern, 60/minute is a hard ceiling you’ll need to design around.

    What “600 Read Requests Per Minute” Actually Means

    Read requests include polling session status, reading agent output, checking checkpoints, and retrieving session state. 600/minute is a relatively generous limit — that’s 10 reads per second. For a monitoring dashboard polling 10 active sessions every second, you’d hit this. For most production monitoring patterns (checking status every 5-30 seconds per session), you’re well under the ceiling.

    The read limit becomes relevant in high-concurrency architectures where many sessions are running in parallel and all being polled aggressively. If you’re running 50 concurrent agents and checking each one every 2 seconds, that’s 25 reads/second — still within the 10 reads/second limit per second, but compressing toward it.

    The Limit That’s More Likely to Actually Stop You

    For most agent workloads, token throughput limits hit before request rate limits do. The reasoning: a long-running agent session processing significant context generates a lot of tokens. If you’re running many such sessions in parallel, you’ll hit your organization’s token-per-minute limit before you hit 60 sessions created per minute.

    Token limits depend on your API tier. Higher tiers have higher token throughput limits. Rate limit increases and custom limits for high-volume enterprise customers are negotiated with Anthropic’s sales team.

    Designing Around the 60 Create Limit

    Diagram comparing a long context window bar with a shorter output limit bar
    Designing around the 60 create limit.

    If your architecture genuinely needs more than 60 new sessions per minute, the primary design pattern is batching more work within each session rather than creating more sessions. A single Managed Agents session can handle sequential tasks — you don’t need a new session per task if your tasks can be queued and processed within one session’s lifecycle.

    The tradeoff: longer-running sessions accumulate more runtime charge ($0.08/hr active). For most workloads, the efficiency gains from batching outweigh the marginal runtime cost.

    The Agent Teams Implication

    Agent Teams — Managed Agents’ multi-agent coordination feature — coordinate multiple Claude instances with independent contexts. Each instance in an Agent Team is a separate entity from a context standpoint. How Agent Team member sessions count against the create rate limit is worth verifying against current documentation if you’re architecting a high-concurrency Agent Teams deployment.

    For Enterprise Workloads

    Desk with laptop, checklist notebook, and billing card ready before creating an Anthropic API key
    For enterprise workloads.

    If you’re evaluating Managed Agents for enterprise-scale deployment and the published limits don’t fit your volume requirements, contact Anthropic’s enterprise sales team. Rate limit increases for high-volume applications are a documented option — they’re negotiated, not self-serve.

    Contact: [email protected] or through the Claude Console.

    Related on Tygart Media: idle-time billing · managed agents review · Claude pricing.

    Frequently Asked Questions

    Does the 60 requests/minute limit apply to all API calls or just session creation?

    The 60/minute limit applies to create endpoints — session creation being the primary one. Read operations have a separate 600/minute limit. Standard Messages API calls are governed by your organization’s standard tier limits, not these Managed Agents-specific limits.

    Do subagents count against the create rate limit separately from the parent session?

    Subagents operate within the parent session’s context and report results upward — they’re architecturally different from new sessions. Verify current documentation for precise billing treatment of subagent creation calls vs. Agent Team session creation.

    What happens when I hit the rate limit?

    Standard API rate limit behavior applies — requests over the limit receive a 429 response. Implement exponential backoff in your session creation logic for any high-volume pattern that approaches the 60/minute ceiling.

    How does this compare to OpenAI’s Agents API limits?

    Rate limit structures differ by product and tier. Direct comparison requires checking both providers’ current documentation for your specific tier. The full comparison: Claude Managed Agents vs. OpenAI Agents API.

    Full pricing context including rate limits: Claude Managed Agents Complete Pricing Reference. All questions: Claude Managed Agents FAQ.

  • What Notion’s Claude Managed Agents Integration Actually Does

    What Notion’s Claude Managed Agents Integration Actually Does

    Tygart Media Strategy
    Volume Ⅰ · Issue 04Quarterly Position
    By Will Tygart • Long-form Position • Practitioner-grade

    When Anthropic launched Claude Managed Agents, Notion was one of four launch partners. That detail got buried in the announcement. Here’s what it actually means for people who use Notion for knowledge work, and why “Notion voice input desktop” keeps showing up as a query against a Managed Agents page.

    Short answer: Managed Agents in Notion is an ambient intelligence layer. It’s not a chatbot in a sidebar. It’s an agent that watches your workspace and acts — without you directing every step.

    What the Notion Integration Actually Does

    Four cards for content, ops, build, and knowledge work with Claude
    What the Notion integration actually does.

    Notion’s Claude Managed Agents integration runs as a persistent background agent with access to your workspace. The practical capabilities, as documented at launch:

    • Autonomous page updates: The agent can read, summarize, and rewrite Notion pages without manual triggers. You set a task; it works through it.
    • Cross-database synthesis: Pull data from multiple Notion databases, synthesize it, and write outputs to a target page or database entry
    • Meeting note processing: Ingest raw meeting notes and produce structured summaries, action items, and task entries in your project database
    • Workflow automation: Trigger actions based on database property changes — a status update in one database can kick off agent work in another

    The key difference from Notion AI (which Notion has had for some time): Notion AI is request-response. You ask it something; it answers. Managed Agents in Notion can be configured to run autonomously on a schedule or on trigger, keep working through multi-step tasks, and report back when done. It’s closer to a background employee than an on-demand assistant.

    Why This Showed Up in Search as “Notion Voice Input Desktop”

    This is worth explaining, because that query cluster is real and mildly interesting. The Managed Agents announcement included voice input functionality — the ability to interact with agents via voice in some contexts. People searching “notion voice input desktop” and “notion ai voice input desktop” were looking for whether this voice capability existed in the desktop client for Notion specifically.

    The honest answer as of April 2026: voice input capabilities are in preview or context-dependent. Verify current availability in Notion’s desktop client against their current documentation — this is an area that may have evolved since launch.

    The “Decoupled Brain and Hands” Model Applied to Notion

    Anthropic describes their Managed Agents architecture as decoupling the brain (Claude, the reasoning layer) from the hands (the sandboxed containers where actions execute). In Notion’s context, this maps cleanly:

    • The brain reads your Notion workspace, understands context, makes decisions about what to do
    • The hands execute — writing to pages, updating database entries, moving content between sections

    The brain and hands operate independently. The agent can reason about what your project needs without being tightly coupled to the specific API calls that will implement it. This matters because it means the agent can handle ambiguity — “clean up the Q2 notes and create action items” is a goal, not a procedure, and the agent figures out the procedure.

    What You Actually Configure

    Three stacked layers: chat UI, tools, agent runtime
    What you actually configure.

    To run Claude Managed Agents in Notion, you’re defining:

    • Task definition: What the agent is supposed to accomplish (in natural language or structured format)
    • Tool access: Which Notion databases, pages, and capabilities the agent can read and write
    • Guardrails: What the agent cannot do — pages it can’t modify, actions it must confirm before taking
    • Trigger: When the agent runs — on schedule, on database trigger, or on demand

    You don’t write the orchestration logic. Anthropic’s infrastructure handles session management, state persistence, and error recovery. If the agent hits an error mid-task, it checkpoints and recovers — you don’t lose progress.

    The Practical Cost of Running Notion Agents

    Using Managed Agents in Notion triggers the same billing as any Managed Agents session: standard token rates plus $0.08/session-hour of active runtime. For typical knowledge work tasks:

    • A daily meeting summary agent running 15 minutes of active execution: ~$0.02/day in runtime (~$0.60/month), plus token costs for the volume of notes processed
    • A weekly database synthesis task running 45 minutes: ~$0.06/run

    For most knowledge workers, the session runtime cost is negligible — the token costs (driven by how much content the agent reads and writes) are the actual variable to model. See the complete pricing reference for worked examples.

    Asana and the Broader Pattern

    Asana was also a Managed Agents launch partner, and the integration pattern is similar: an agent that can read project data, update task statuses, move cards, and generate project summaries without constant human direction. The launch partner list (Notion, Asana, Rakuten, Sentry) suggests Anthropic targeted three categories: knowledge management (Notion), project management (Asana), enterprise operations (Rakuten), and developer tools (Sentry).

    That’s a deliberate wedge. If agents can handle the administrative layer of these four categories, the surface area for autonomous business work expands significantly.

    What This Means for How You Work

    Desk with laptop, checklist notebook, and billing card ready before creating an Anthropic API key
    What this means for how you work.

    The honest use case for most people reading this: you have a Notion workspace with databases that need regular synthesis, and you’re currently doing that manually. Managed Agents is the path to automating that synthesis without building and maintaining a custom integration.

    The constraint worth naming: you’re running your workspace data through Anthropic’s infrastructure. That’s the trade-off. For most knowledge work, the data sensitivity concern is low. For anything involving client data, legal documents, or proprietary strategy — read Anthropic’s data handling terms before configuring access.

    For the full Managed Agents setup and pricing context: Claude Managed Agents: Every Question Answered. For the enterprise deployment pattern: How Rakuten Deployed 5 Enterprise Agents in a Week.

    Related on Tygart Media: managed agents review · Notion Command Center · managed agents memory use cases.

  • Claude Managed Agents — Every Question Answered (Complete FAQ 2026)

    Claude Managed Agents — Every Question Answered (Complete FAQ 2026)

    Tygart Media Strategy
    Volume Ⅰ · Issue 04Quarterly Position
    By Will Tygart • Long-form Position • Practitioner-grade

    Everything people actually ask about Claude Managed Agents, answered straight. No preamble about “the exciting world of AI agents.” If you’re here, you already know why this matters — you just need answers.

    This page covers pricing, setup, capabilities, limits, comparisons, and the specific questions that don’t have obvious homes in Anthropic’s documentation. It updates as the beta evolves.

    Context

    Claude Managed Agents launched April 8, 2026 as a public beta. All answers reflect current documentation as of April 2026. Beta details change — verify specifics at platform.claude.com/docs.

    Pricing Questions

    Workshop fuel gauge and metal tokens pouring into an API hopper, metaphor for pay-per-token pricing
    Pricing questions — stale-proof framing.

    What does Claude Managed Agents cost?

    Two charges: standard Claude API token rates (same as calling the Messages API directly) plus $0.08 per session-hour of active runtime. That’s the complete formula. See the complete pricing reference for worked examples by workload type.

    What exactly is a “session-hour” and when does it start billing?

    A session-hour is one hour of active session runtime — time when your session’s status is running. Billing is metered to the millisecond. It does not accrue during idle time, time waiting for your input, time waiting for tool confirmations, or after session termination.

    What’s included in the $0.08/session-hour charge?

    The session runtime charge covers Anthropic’s managed infrastructure: sandboxed code execution containers, state management, checkpointing, tool orchestration, error recovery, and scaling. You are not separately billed for container hours on top of session runtime.

    Does the $0.08/hr apply even if my agent is just waiting?

    No. Time spent waiting for your message, waiting for tool confirmations, or sitting idle does not accumulate runtime charges. Only active execution time counts.

    What does web search cost inside a Managed Agents session?

    $10 per 1,000 searches ($0.01 per search), billed separately from session runtime and token costs. This is the same rate as web search through the standard API.

    Are there volume discounts?

    Yes, negotiated case-by-case for high-volume users. Contact [email protected] or through the Claude Console.

    How does Managed Agents pricing compare to running my own agent infrastructure?

    The $0.08/session-hour is almost always cheaper than equivalent provisioned compute — but you trade infrastructure control and data locality for that simplicity. For a full comparison: Build vs. Buy: The Real Infrastructure Cost.

    What’s the real monthly cost if I run an agent 24/7?

    Maximum theoretical session runtime: 24 hrs × $0.08 × 30 days = $57.60/month. In practice, no production agent has zero idle time. Token costs become the dominant cost driver long before you hit the runtime ceiling. Detailed breakdown: The Real Monthly Cost of Running Claude Managed Agents 24/7.

    Setup and Access Questions

    Four-step loop: observe, remember, act, update for managed agents
    Setup and access questions.

    How do I get access to Claude Managed Agents?

    Available to all Anthropic API accounts in public beta — no separate signup. You need the managed-agents-2026-04-01 beta header in your API requests. The Claude SDK adds this header automatically.

    Does it work with my existing API key?

    Yes. Same API key you’re already using for the Messages API. Same authentication. The beta header is the only new requirement.

    What three ways can I access Managed Agents?

    Via the Claude SDK (recommended — handles the beta header automatically), via direct API calls with the beta header, or via the Claude Console’s new Managed Agents section for no-code agent configuration and session tracing.

    Can I use Managed Agents through AWS Bedrock or Google Vertex AI?

    Managed Agents runs on Anthropic-managed infrastructure. This is distinct from Bedrock and Vertex AI deployments. Check Anthropic’s current documentation for multi-cloud availability status — this is an area of active development.

    Capability Questions

    What can Claude Managed Agents actually do?

    Run long autonomous sessions with persistent state, execute code in sandboxed Linux containers, use tools including web search and MCP servers, coordinate multiple Claude instances via Agent Teams, and maintain checkpoints for crash recovery. The session can last minutes or hours without you staying in the loop.

    What’s the difference between Agent Teams and subagents?

    Agent Teams coordinate multiple Claude instances with independent contexts, direct agent-to-agent communication, and a shared task list — suited for complex parallel tasks. Subagents operate within the same session as the main agent and only report results upward — more economical for sequential targeted tasks but less capable of true parallelism.

    Does it support MCP servers?

    Yes. MCP servers can be integrated as tool sources in Managed Agents sessions, extending what the agent can access and act on.

    How long can a session run?

    Anthropic’s documentation currently references session durations of minutes to hours. Claude Code’s longest autonomous sessions have reached 45 minutes. Managed Agents is architected for longer-running work. Check current documentation for specific session duration limits as the beta matures.

    What happened to Claude Code — is it the same as Managed Agents?

    No. Claude Code is a separate local coding workflow product. Anthropic’s docs explicitly note partners should not conflate the two. Managed Agents is a hosted API runtime service. Claude Code is a developer tool. Different products, different use cases, different billing.

    Rate Limit Questions

    Infographic with three panels: protect the service, fair share, and cost control explaining rate limits
    Rate limit questions.

    What are the rate limits for Managed Agents?

    60 requests per minute for create endpoints; 600 requests per minute for read endpoints. Organization-level API limits still apply on top of these. For higher limits, contact Anthropic enterprise sales. Detailed breakdown: Claude Managed Agents Rate Limits Explained.

    Do standard Claude API rate limits still apply inside a session?

    Organization-level limits apply. The session runtime and create/read endpoint limits are Managed Agents-specific. If you’re running many parallel Agent Teams, model token throughput limits will become relevant.

    Comparison Questions

    How does Managed Agents compare to OpenAI’s Agents API?

    Both offer hosted agent infrastructure. Key differences: Managed Agents is Claude-native (no multi-model flexibility), sessions bill on runtime + tokens vs. OpenAI’s different pricing model, and lock-in dynamics differ. Full comparison: Claude Managed Agents vs. OpenAI Agents API.

    Should I use Managed Agents or the Claude Agent SDK?

    Use Managed Agents when you want Anthropic to host the runtime — less infrastructure work, faster to production. Use the SDK when you need tighter loop control, on-premise execution, or multi-cloud flexibility. Anthropic’s own migration docs draw this line clearly: SDK runs in your environment; Managed Agents runs in theirs.

    What companies are already using Managed Agents in production?

    Notion, Asana, Rakuten, Sentry, and Vibecode were launch partners. Rakuten deployed five enterprise agents within a week. Allianz is using Claude for insurance agent workflows. Anthropic’s run-rate from the agent developer segment exceeds $2.5 billion. How Rakuten did it in a week →

    Data and Security Questions

    Where does my data go when running in Managed Agents?

    Execution runs on Anthropic’s infrastructure. This is the explicit trade-off: you get managed infrastructure; they manage the compute. For companies with strict data sovereignty requirements, this is the key constraint to evaluate. On-premise or native multi-cloud deployment is not currently available.

    What are the sandboxing guarantees?

    Anthropic uses disposable Linux containers — “decoupled hands” in their terminology. Each container is a fresh sandboxed environment for code execution. State persistence is managed separately from the execution environment.

    Strategic Questions

    Is this a bet worth making?

    That depends on your switching cost tolerance. Lock-in is real: once your agents run on Anthropic’s infrastructure with their tools, session format, and sandboxing, switching providers isn’t trivial. The counter-argument: the infrastructure you’d otherwise build to match this is months of engineering. One developer’s reaction at launch was blunt: “there goes a whole YC batch.” That captures both the opportunity and the risk. Our take on why we’re staying our course →

    What does this mean for AI citation and visibility?

    Agents running on Anthropic’s infrastructure make decisions about what content to surface, cite, and synthesize. As agent workloads grow, being present in the knowledge sources agents draw from becomes a search strategy question in itself. What AI citation monitoring looks like →

  • Claude Managed Agents — Complete Pricing Reference + Dreaming Update (May 2026)

    Claude Managed Agents — Complete Pricing Reference + Dreaming Update (May 2026)

    Last refreshed: May 15, 2026

    May 2026 Update — Dreaming Feature + Beta Status

    Anthropic introduced Dreaming at Code w/ Claude (May 6, 2026) — a new Managed Agents capability where agents review their own session history overnight to improve future performance. Harvey (legal AI) reported a roughly 6× task completion rate increase after implementing it. Dreaming is developer-access preview only. Multiagent Orchestration and Outcomes are now in public beta. See the new Dreaming section below.

    What Is Claude Managed Agents? (Current Status, May 2026)

    Four-step loop: observe, remember, act, update for managed agents
    What Claude Managed Agents is right now.

    Claude Managed Agents is Anthropic’s framework for long-running, stateful AI agents — agents that can maintain context across sessions, hand off between sub-agents, and now, improve themselves by reviewing their own work history. Here’s the current status of each component:

    Component Status Who Has Access
    Multiagent Orchestration Public Beta All API developers
    Outcomes Public Beta All API developers
    Dreaming Developer Preview Selected developers only

    Dreaming: The Feature the Press Mostly Missed

    Three stacked layers: chat UI, tools, agent runtime
    Dreaming — the feature the press mostly missed.

    Announced at Code w/ Claude on May 6, 2026, Dreaming is a Managed Agents capability that lets agents review and reorganize their own memory between sessions. The mechanism:

    1. After a session ends, the agent reads its existing memory store alongside the session transcripts
    2. It produces a new, reorganized memory store: duplicates merged, stale entries replaced, new patterns surfaced
    3. The next session starts with a higher-quality knowledge base — capturing insights no single session could hold

    This is meaningfully different from simply persisting conversation history. The agent isn’t just remembering what happened — it’s synthesizing what it learned. Think of it as the difference between taking notes and actually reviewing and reorganizing your notes the next morning.

    The Harvey Result

    Harvey, the legal AI company, reported approximately a 6× task completion rate increase after implementing Dreaming in their Managed Agents workflow. Harvey’s use case — complex legal research that spans multiple sessions with evolving context — is exactly the kind of work Dreaming was designed for. Sessions build on each other rather than starting fresh each time.

    Dreaming is developer-access preview as of May 2026. Docs: platform.claude.com/docs/en/managed-agents/dreams.

    What Dreaming Is Not

    A few clarifications worth making explicit:

    • Dreaming is not available to end users — it’s a developer-layer capability requiring implementation
    • It’s not persistent memory in the claude.ai chat interface
    • It’s not available to free or standard Pro subscribers through any interface
    • It’s a developer preview, not GA — expect it to evolve before full release

    Our Take: Why This Architecture Matters

    We run Managed Agents in our own Cowork workflows. The Dreaming announcement is the first time Anthropic has shipped something that resembles how expert human knowledge actually compounds over time — not by accumulating raw notes, but by periodically synthesizing and reorganizing what’s been learned into a cleaner structure.

    The Harvey 6× result is a real-world data point from a production legal AI workflow. That’s not a benchmark number — it’s a deployed system showing measurable improvement from session-to-session memory refinement. Whether that 6× figure holds across different use cases is unknown, but the direction of the effect is the signal: agents that learn from their own history outperform agents that don’t.

    For non-developer users watching this space: Dreaming is the preview of what agentic AI will look like when it becomes mainstream. The groundwork being laid now in developer preview will eventually surface in subscription-tier products.

    Model Accuracy Note — Updated May 2026

    Current flagship: Claude Opus 4.7 (claude-opus-4-7). Current models: Opus 4.7 · Sonnet 4.6 · Haiku 4.5. Claude Opus 4.7 (claude-opus-4-7) is the current flagship as of April 16, 2026. Where this article references Opus 4.6 or earlier models, those references are historical. See current model tracker →. See current model tracker →

    Tygart Media Strategy
    Volume Ⅰ · Issue 04Quarterly Position
    By Will Tygart
    • Long-form Position
    • Practitioner-grade

    You opened this tab because you need a number you can actually use. Not a vibe, not “it depends.” A real pricing breakdown you can put in a spreadsheet, a budget request, or a Slack message to your CTO.

    This is that page. Every pricing variable for Claude Managed Agents in one place, verified against Anthropic’s current documentation as of April 2026. Bookmark it. The beta will update; so will this.

    Quick Reference: The Formula

    Total Cost = Token Costs + Session Runtime ($0.08/hr) + Optional Tools
    Session runtime only accrues while status = running. Idle time is free.

    The Two Cost Dimensions

    Workshop fuel gauge and metal tokens pouring into an API hopper, metaphor for pay-per-token pricing
    Two cost dimensions — stale-proof framing.

    Claude Managed Agents bills on exactly two dimensions: tokens and session runtime. Every pricing question you have collapses into one of these two buckets.

    Dimension 1: Token Costs

    These are identical to standard Claude API pricing. You pay the same rates you’d pay calling the Messages API directly. No Managed Agents markup on tokens. Current rates for the models most commonly used in agent work:

    • Claude Sonnet 4.6: ~$3/million input tokens, ~$15/million output tokens
    • Claude Opus 4.7: higher rates apply — check platform.claude.com/docs/en/about-claude/pricing for current figures
    • Prompt caching: same multipliers as standard API — cache hits dramatically reduce input token costs on long sessions with stable system prompts

    The implication: a token-heavy agent with a large system prompt that runs the same context repeatedly benefits significantly from prompt caching, and that benefit carries over unchanged into Managed Agents.

    Dimension 2: Session Runtime — $0.08/Session-Hour

    This is the Managed Agents-specific charge. You pay $0.08 per hour of active session runtime, metered to the millisecond.

    The critical word is active. Runtime only accrues while your session’s status is running. The following do not count toward your bill:

    • Time spent waiting for your next message
    • Time waiting for a tool confirmation
    • Idle time between tasks
    • Rescheduling delays
    • Terminated session time

    This is not how you’d bill a virtual machine. It’s closer to how AWS Lambda bills — you pay for execution, not reservation. An agent that “runs” for 8 hours but spends 6 of those hours waiting on human input has a very different bill than one running continuous autonomous loops.

    Optional Tool Costs

    Web Search: $10 per 1,000 Searches

    If your agent uses web search, each search costs $10/1,000 — that’s $0.01 per search. For most agents, this is negligible. For a research agent running hundreds of searches per session, it becomes a line item worth modeling separately.

    Code Execution: Included in Session Runtime

    Code execution containers are included in your $0.08/session-hour charge. You’re not separately billed for container hours on top of session runtime. This is explicitly stated in Anthropic’s docs and represents meaningful savings versus provisioning your own compute.

    Worked Cost Examples

    Example 1: Daily Research Agent

    Runs once per day. 30 minutes of active execution. Processes 10 documents, outputs a summary report. Moderate token volume.

    • Session runtime: 0.5 hrs × $0.08 = $0.04/day (~$1.20/month)
    • Tokens (estimate): 50K input + 5K output with Sonnet 4.6 = ~$0.23/run (~$7/month)
    • Total: ~$8–10/month

    Example 2: Weekly Batch Content Pipeline

    Runs 3x/week. 2-hour active sessions. Processes multiple documents, generates structured outputs.

    • Session runtime: 2 hrs × $0.08 × 12 sessions/month = $1.92/month
    • Tokens: depends on content volume — typically $10–40/month
    • Total: ~$12–42/month

    Example 3: Customer Support Agent (Business Hours)

    Active during business hours, handling tickets. 8 hours/day active, 5 days/week.

    • Session runtime: 8 hrs × $0.08 × 22 days = $14.08/month in runtime
    • Tokens: highly variable by ticket volume — the dominant cost driver at scale
    • Runtime cost alone: ~$14/month — tokens are likely 5–20x this depending on volume

    Example 4: 24/7 Always-On Agent

    The maximum theoretical runtime exposure. Continuous operation, no idle time.

    • Session runtime: 24 hrs × $0.08 × 30 days = $57.60/month
    • In practice, no agent has zero idle time — real cost will be lower
    • Token costs at this scale become the dominant factor by a wide margin

    Anthropic’s Official Example (from their docs)

    A one-hour coding session using Claude Opus 4.7 consuming 50,000 input tokens and 15,000 output tokens: session runtime = $0.08. With prompt caching active and 40,000 of those tokens as cache reads, the token costs drop significantly. The runtime charge stays flat at $0.08 regardless of caching.

    What’s Not Billed in Managed Agents

    A few things that might seem like costs but aren’t:

    • Infrastructure provisioning: Anthropic handles hosting, scaling, and monitoring at no additional charge
    • Container hours: Explicitly not separately billed on top of session runtime
    • State management and checkpointing: Included in the session runtime charge
    • Error recovery and retry logic: Anthropic’s infrastructure problem, not yours

    Rate Limits

    Managed Agents has specific rate limits separate from standard API limits:

    • Create endpoints: 60 requests/minute
    • Read endpoints: 600 requests/minute
    • Organization-level limits still apply
    • For higher limits, contact Anthropic enterprise sales

    How to Access Managed Agents Pricing

    Managed Agents is available to all Anthropic API accounts in public beta. No separate signup, no premium tier gate. You need the managed-agents-2026-04-01 beta header in your API requests — the Claude SDK adds this automatically.

    For high-volume agent applications, Anthropic’s enterprise sales team negotiates custom pricing arrangements. Contact them at [email protected] or through the Claude Console.

    The Pricing Signals Worth Noting

    Anthropic recently ended Claude subscription access (Pro/Max) for third-party agent frameworks, requiring those users to switch to pay-as-you-go API pricing. This signals a deliberate strategy: consumer subscriptions are for human-paced interactions; agent workloads route through the API. The $0.08/session-hour rate exists in that context — it’s infrastructure pricing for compute that runs beyond human attention spans.

    The session-hour model also signals something about Anthropic’s infrastructure cost structure. They’re pricing on active execution time because that’s what actually taxes their systems. Idle sessions don’t cost them much; active agents do. The billing model follows the actual resource consumption pattern.

    Frequently Asked Questions

    Is the $0.08/session-hour charge in addition to token costs, or does it replace them?

    In addition to. You pay both: standard token rates for all input and output tokens, plus $0.08 per hour of active session runtime. They’re separate line items.

    Does prompt caching work in Managed Agents sessions?

    Yes. Prompt caching multipliers apply identically to Managed Agents sessions as they do to standard API calls. If your agent has a large, stable system prompt, caching it can significantly reduce input token costs.

    What happens if my session crashes? Am I billed for the crashed time?

    Runtime accrues only while status is running. Terminated sessions stop accruing. Anthropic’s infrastructure handles checkpointing and crash recovery — the session state is preserved even if the session terminates unexpectedly.

    Can I use Managed Agents on the free API tier?

    Managed Agents is available to all Anthropic API accounts in public beta, but standard tier access and rate limits apply. Free API tier users receive a small credit for testing.

    How does this compare to running agents on my own infrastructure?

    See our full breakdown: Build vs. Buy: The Real Infrastructure Cost of Claude Managed Agents. Short version: the $0.08/hour is almost certainly cheaper than provisioning and maintaining equivalent compute, but you trade control and data locality for that simplicity.

    Are there volume discounts?

    Volume discounts are available for high-volume users but negotiated case-by-case. Contact Anthropic enterprise sales.

    Does web search billing count against the $10/1,000 rate if the search returns no results?

    Anthropic’s current docs don’t explicitly address failed searches. Treat any triggered search as billable until confirmed otherwise.

    For the full session-hour math worked out by workload type, see: Claude Managed Agents Pricing, Decoded: What a Session-Hour Actually Costs You. For the build-vs-buy infrastructure comparison: Build vs. Buy: The Real Infrastructure Cost. For enterprise deployment patterns: Rakuten Stood Up 5 Enterprise Agents in a Week.