Opus 4.6: Long Context and Agent Teams for Everyday Business Work

A one-million-token context window sounds like a technical specification until you realize what it means for a business that has spent years accumulating documents it has never had time to read together. I am Madhuranjan Kumar, and this playbook is for the fitness studio, the legal office, the clinic, and the service business that has a year of feedback forms, session logs, financial summaries, and attendance records sitting in folders it only opens one at a time. Opus 4.6 lets you load all of it at once and ask a single question across the whole stack. This playbook is how to do that without wasting tokens, inflating costs, or getting worse results by loading more than you need.

The three capabilities in Opus 4.6 that this playbook draws on are the expanded context window, the agent team architecture, and the per-task effort controls. The context window is large enough to hold a year of operational documents for most small businesses without splitting them. The agent team architecture lets large projects run in parallel streams instead of sequentially. The effort controls let you dial the model's reasoning intensity up for complex jobs and down for routine ones, so you only pay for deep analysis when the task warrants it. Used together with the discipline described in each step below, these three capabilities change what a document-heavy small business can know about itself and how fast it can act on that knowledge.

Identify the document pile that costs you the most time to analyze manually

The first step is not loading anything. It is identifying which set of documents, if analyzed together, would produce the most useful insight for your business right now. The most valuable document pile is almost always the one you currently avoid analyzing because doing it manually takes too long.

For most businesses, this pile falls into one of three categories. The first is historical performance data: attendance logs, sales records, appointment histories, or production reports that span months or years and would reveal patterns no one has had time to extract. The second is accumulated customer input: feedback forms, review responses, inquiry emails, or session notes that contain recurring themes and specific complaints the business knows exist but has never quantified. The third is cross-document decisions: situations where the right decision requires comparing information from multiple sources that are currently stored separately, such as pricing against competitor research, or staffing levels against attendance patterns by time slot.

For a fitness studio, the most valuable pile is usually a combination of the first two: class attendance records by time slot and instructor, member feedback forms collected over twelve months, and seasonal promotion performance data showing which offers drove the most new sign-ups and which members they retained. That pile sits across multiple spreadsheets and email threads and has never been read in full as a combined dataset. It contains the answers to questions the owner asks every month without being able to answer precisely: which classes should be scheduled at which times, which member segments are most loyal, and which promotions are worth repeating.

Identifying this pile before any loading begins also tells you the question you are going to ask, which determines whether the session produces a useful result or a generic summary. Start with the question, then identify the documents that contain the answer.

Load focused, relevant material rather than everything you own

A one-million-token window creates a tempting mistake: loading everything you have on the assumption that more context produces better answers. It does not. More context increases the volume of material the model must reason across, which takes longer and introduces more noise. The model has to work harder to find the signal in a larger pile, and the signal it finds is less precise when it is surrounded by unrelated material.

The right approach is to load the specific set of documents that contains the answer to the question you identified in the first step. For the fitness studio question about class scheduling and member loyalty, that means loading one year of class attendance logs, one year of member feedback forms, and the results of the last three seasonal promotions. It does not mean loading every email the studio has ever sent, every vendor invoice, or every staff schedule. Those documents are not irrelevant to the business, but they are irrelevant to the question being asked in this session.

A useful filter before loading any document is to ask: if I were reading this by hand to answer my question, would this document contain anything I would write down? If the answer is no, leave it out of the session. If the answer is yes, include it. That filter keeps the loaded context focused and the model's reasoning precise.

Document preparation matters too. A spreadsheet exported as a formatted CSV is easier for the model to reason over than the same spreadsheet exported as a locked PDF. Feedback forms compiled into a single document with clear separation between entries are easier to analyze than a folder of individual form submissions. Ten minutes of preparation before loading can produce significantly better results than the same session run on poorly structured raw files.

Write specific questions into long-context sessions, not broad prompts

The output quality of a long-context session is determined more by how the question is written than by the quantity of documents loaded. A broad prompt, "analyze my attendance data," produces a broad answer. A specific question, "which class time slot has the highest average attendance per active member, and is there a pattern in how long members who attend that slot stay subscribed compared to the studio average," produces a specific answer that is immediately usable for a decision.

For the fitness studio, the specific questions that produce the most actionable results are ones that cross document types. Not just "what are the most attended classes," because that answer is available from a single spreadsheet. But "what is the relationship between when a member first signs up, which class they attend in their first month, and how long they remain a member," because that answer requires reading across the attendance log, the sign-up records, and the membership duration data together. That cross-document analysis is exactly what the one-million-token context window enables, and it is only accessible through questions that are specific enough to require it.

The practical output of this kind of session for the fitness studio is a finding like this: members who attend Tuesday evening yoga within their first thirty days retain for an average of eleven months, compared to a studio-wide average of seven months. That finding, which could not have been extracted from any single document, directly informs the renewal pricing offer for that member segment. A studio that knows Tuesday evening yoga members stay longer can make a calibrated decision about offering them a higher-value renewal incentive rather than the same discount it offers every member at month six.

Write the question before you open the session. Specific questions produce specific answers. Broad prompts produce summaries that feel useful and lead to no action.

Reserve agent teams for tasks where the work genuinely runs in parallel streams

Agent teams are not a default upgrade over single sessions. They are a specific tool for a specific kind of task: one where the work can be divided into independent streams that genuinely run at the same time, where each stream does not need to wait for another to finish before it can begin. For those tasks, teams compress the timeline significantly. For tasks with a sequential structure, teams add coordination overhead without adding speed.

The seasonal planning project is the right use case for a fitness studio agent team. The lead agent manages the scope of the project: redesigning the class schedule and pricing structure for the next quarter. Teammate one analyzes the attendance data from the long-context session and produces a structured finding about which time slots are underperforming and which have unmet demand at their current capacity. Teammate two takes those findings and drafts a new schedule structure, working on its section while teammate one is still analyzing. Teammate three writes the member announcement for the schedule changes in the studio's communication tone, beginning from the general parameters the lead agent defined, and refining based on the specific changes teammate two drafts. Each works in its own context on its assigned piece, they exchange findings as they become available, and the lead synthesizes the full output into a final recommendation.

The work is genuinely parallel because the announcement framework can begin before the exact new schedule is finalized, and because the analysis and the design can proceed simultaneously with each informing the other as findings emerge. The total time to produce a complete seasonal planning document drops significantly compared to a sequential single-session approach. For a decision that affects the studio's revenue for the next three months, the extra token cost of running three agent teammates is well justified.

The tasks that do not belong in an agent team are the ones where each step depends on the previous step completing before it can begin. Writing the member announcement depends entirely on knowing what the schedule changes are. If that is the only task, a single session handles it faster and more cheaply than a team where one agent is waiting for another to finish before it can do anything meaningful. Evaluate whether the work genuinely runs in parallel before deciding a team setup is appropriate.

Set per-task effort levels from day one to keep monthly cost predictable

The effort controls in Opus 4.6 are not a detail to configure after the system is running. They are a cost management tool that should be set from the first session. The model can reason at different depths depending on the effort level you assign: high effort produces more careful, more thorough reasoning for complex tasks; low effort produces faster, cheaper responses for routine ones. If you do not set effort levels, the model defaults to a middle setting that is neither optimally fast nor optimally precise, and costs more per month than a deliberate effort strategy would.

For the fitness studio, the effort tier structure is straightforward. Low effort is correct for routine member emails, standard FAQ responses, and any task where the output follows a clear template that does not require analysis. The model produces a draft faster and at lower cost, which is appropriate because the value of a standard member communication email does not justify the cost of deep reasoning. Medium effort is appropriate for single-document summaries, individual class performance reviews, and short planning notes: tasks that benefit from more careful reading than a low-effort pass but that are not complex enough to warrant the highest tier.

High effort is reserved for the long-context cross-document analysis sessions and the agent team seasonal planning projects, where precision matters and the decisions are consequential enough to justify the higher cost. The fitness studio uses high effort twice a quarter, for the seasonal schedule review and the member retention analysis. Everything else runs at low or medium. Setting these tiers explicitly from the first week produces a monthly cost pattern that is predictable and tied to the value each task generates.

Over a quarter, the difference between a deliberate effort strategy and no strategy compounds into a meaningful cost difference while the output quality for the tasks that genuinely need high effort stays exactly the same. The studio's total monthly cost for running the system reflects what it actually uses the high-end reasoning for, not a flat assumption that every task needs the same depth of analysis. The effort controls are the mechanism that makes a powerful model affordable for a small business over the long run, and setting them from day one rather than discovering them after the first large bill is the habit that keeps the cost predictable without limiting the capability when it matters.

The playbook in this document is a starting sequence, not a complete system. Every business that runs through these five steps will find at least one thing that should be adapted for its specific document types, its specific questions, and the parallel structure of its specific planning work. The starting sequence gives you a working system. The adaptations you make after the first month give you the system that actually fits how your business runs.