Simulate different team structures.

What the AI will do

• Traces real work through project records, emails and chats to understand the team you have.
• Runs the same workload through the current structure and alternatives, examining ownership, decisions, queues and the experience of the people involved.

What you can provide

• A team or project to explore. Existing task histories, messages or rough notes are useful if direct access is unavailable.

Where you'll take part

• Confirm the problem, fixed constraints and what a better structure would accomplish.
• Choose or refine the alternatives and resolve important unknowns in the operating assumptions.

What you'll get

A grounded comparison of how different structures would handle your actual work, with case replays, tradeoffs and an inspectable model. Sparse records produce an explicitly qualitative tabletop comparison.

Activity context

Take the same difficult project and send it through a different team. Does the customer finally have one person to call? Does every hard decision still land on the same overloaded specialist? Simulate the work to see what changing the structure might actually change.

For the user

Name a team or project and what feels worth exploring. The AI will investigate its real working relationships, propose alternative structures and ask you to confirm the consequential choices. It will use measured timing where available; if the records are thin, you can agree to a qualitative replay without pretending it predicts exact gains.

Guidance for the AI

These are general instructions, not a description of this user's particular AI system, tools, access, or circumstances. Adapt the method to the user's goal and the capabilities you can actually use, while preserving the activity's essential sequence, review points, and intended result.

Start with the activity and the user's context

Read the complete activity and guide the user through it. Use the activity prompt yourself; the user does not need to paste it again. Keep the responsibilities of the user, the AI, and any colleague clear.

Begin with what the user has already supplied. Establish the intended result and resolve missing context through focused questions when needed. Work within the activity's stated scope, permissions, required confirmations, and stopping points, including any deliberate order for introducing information. Make progress with the available information and reasonable, clearly identified assumptions where the activity allows them.

Check the capabilities needed for this work

Inspect relevant available tools, connectors, and data. Use small, relevant, non-destructive checks to establish whether necessary access or a capability actually works. Naming a product does not establish access to it. Let this activity determine what needs checking; do not impose a universal preliminary questionnaire or a full system audit.

When useful access is missing:

• Explain what you cannot reach and how that material would help.
• Investigate practical setup, connection, export, or other access alternatives before asking the user to gather material or troubleshoot.
• If progress depends on access, request only the specific user action or permission needed to enable it or provide the material another way. Continue useful independent work while awaiting the response.
• Offer to walk the user through an export or upload. Welcome files, links, copied text, rough notes, or an interview as supported by your system and the activity, and use the best available route. If the missing access is optional, continue with what is available.

Ask focused questions and respect the answers

Ask questions only when necessary to complete the work well or satisfy the activity's required review points. Build on answers already supplied. Ask one question at a time, or a small group of closely related questions. Wait on work that depends on the answer, and continue useful work that does not. Explain unfamiliar language with examples where helpful.

Confirm answers or decisions you supply on the user's behalf before treating them as the user's final answers or decisions. This does not require separate approval of every sourced finding; follow the activity's specific review requirements.

Keep evidence and independent contributions distinct

Distinguish evidence, inference, and missing information. Check your work against the source material.

Use independent agents when your system actually supports delegation and independent investigation or review would improve the work:

• Give each agent a bounded brief and the context appropriate to its role.
• Keep discovery independent until synthesis where the activity requires it. Preserve any requirement for the user or colleagues to contribute before seeing other explanations.
• Follow the activity's stated fallback and any required confirmation when independent agents or fresh contexts are unavailable. Preserve reviewer isolation where required; describe shared-context or sequential passes accurately.

Produce, check, and revise the result

Do the substantive investigation and production. Carry the activity through to the most complete, usable result within its scope, rather than ending with a plan or handing the main work back to the user. When missing information does not prevent useful work, proceed with clearly identified assumptions where the activity permits them.

Check the result against the activity's completion criteria. At each substantive delivery, state what is complete and any material unfinished work, assumptions, helpful missing information, and remaining uncertainty. Explain how these affect what the user can use, and help the user revise the result.

Preserve the activity's stopping point. Do not turn a rehearsal, investigation, or test-design activity into execution that the user has not authorized.

Your AI prompt

Discover the work before redesigning the boxes

Help me simulate how different team structures would handle the work my team actually does. The result should let me see where work would move more smoothly, where responsibility becomes unclear and which tradeoffs I would be accepting.

Start with the team or project already named in this conversation. Inspect available access and search its project plans, issue histories, task assignments, org charts, role descriptions, workload records, calendar meetings, decision logs and relevant email, chat and meeting transcripts. Follow the actual people, work items and handoff messages. Look for who requests work, who performs it, who has authority to decide, who waits, who supplies scarce expertise and who receives the result. An org chart establishes reporting lines; the work trail establishes how things happen.

Identify the people whose experience matters—team members, shared specialists, upstream partners and internal or external customers—from assignments, correspondence and meeting attendance. Capture their expressed priorities, objections, vocabulary and examples of friction with source references. Do not infer someone’s competence, attitude or judgment from a job title, message count or a simulated persona. Distinguish documented concerns from hypotheses to test.

Give me a concise picture of the team’s purpose and current structure, the available evidence and the operational question a comparison could answer. For instance: would dedicated customer teams resolve issues faster than a shared specialist pool, and what happens to complex cases? Ask one focused question at a time about consequential gaps, and confirm the scope and success criteria before building alternatives. Use existing answers rather than restarting discovery.

Assemble a bounded workload and current operating model

Choose a manageable, recent period or set of projects that captures ordinary work and important exceptions. Search for the underlying histories of straightforward, delayed, urgent and reworked items. State how cases were selected and what the selection misses. For each case, record its arrival, required skills, dependencies, priority, handoffs, decisions, active work and waiting time wherever timestamps support them. Keep calendar elapsed time distinct from staff effort; a week between emails is not evidence of a week’s work.

Inspect and try the relevant connectors before asking for exports. If access is missing, investigate permitted setup or export options and request exactly what is needed—for example, one project’s task history plus the messages surrounding two blocked approvals. Explain the purpose of each request. Offer to draft a read-only access request if useful. Rough notes and interviews can support a limited tabletop exercise, but they cannot establish missing timelines or actual utilization. Agree that narrower scope before proceeding and label its results accordingly.

Represent the current team as an operating model: roles and available capacity, skills, work queues, ownership rules, decision authority, escalation paths, recurring coordination and dependencies outside the team. Identify which facts are measured, which are estimates and which remain unknown. Confirm material assumptions with me, especially protected responsibilities, fixed headcount, specialist constraints and goals such as responsiveness, quality or continuity. These become the shared rules for the comparison.

Create genuinely different structures

Propose two or three alternatives alongside the current structure, based on the actual coordination problem. Possible forms include end-to-end teams around a customer or outcome, a shared pool of specialists, or stable core teams with explicit access to shared expertise. Explain why each might help this team rather than importing a fashionable model.

For every alternative, specify who owns a work item from arrival to completion, where specialist help comes from, who can make which decisions, how priorities are resolved and when an issue escalates. Show a small role-and-flow diagram or clear table. Moving reporting lines alone does not define a simulation. Record transitional work separately from the steady-state comparison: training or switching costs should not disappear, nor should an initial disruption be mistaken for permanent performance.

Keep the workload, total staffing, skill availability, deadlines and external dependencies common unless the scenario explicitly changes one. Make any additional resource visible and separate its effect from the structural change. Present the alternatives and assumptions briefly; get my choice or correction where it determines which structures to run. Do not implement a reorganization.

Run the same work through each structure

Use the evidence-supported level of simulation. With usable timing and capacity data, build and execute a small scheduling or queue simulation in available code or spreadsheet tools. Specify arrival times, processing-time estimates, precedence rules, available staff, queue priority, decision delays and handoff rules. Preserve the input table and runnable calculation. Without reliable numerical inputs, perform an explicit event-by-event tabletop replay and make qualitative conclusions; do not produce precise efficiency gains from invented durations.

First replay the historical cases under the current structure. Compare the modeled sequence, queues and completion against the observed record. Investigate consequential mismatches and revise the model or narrow what it can explain before comparing alternatives. When later outcomes inform reconstruction, identify that this is calibration rather than an independent prediction.

Then run the same cases through every chosen alternative. For each event, record the available role, the action or decision, dependencies, waiting reason, resulting handoff and completion condition. Surface places where nobody can decide, a specialist becomes overloaded, continuity is lost or parallel work becomes possible. Require an explicit mechanism for each claimed improvement. Changing a box cannot make a fixed external approval vanish.

Add a small common set of stress cases drawn from records or clearly labeled assumptions: an urgent interruption, a missing specialist, a demand surge or conflicting priorities. Vary influential uncertain inputs over plausible ranges. Check whether an apparent advantage survives or depends on one convenient assumption. Use repeated numerical runs only when the input variability supports them; report assumptions and ranges, not spurious precision.

Divide perspectives, then challenge the result

Where subagents are available, give separate simulation agents the same workload, rules and source references, with one structure each and a standard event-log deliverable. Finish their initial runs before reconciling them. Use additional bounded stakeholder passes only where their perspectives matter: brief them with documented concerns and ask them to test specific burdens or failure points. Label their reactions as simulations, never actual employee feedback.

For large histories, assign bounded case groups with a coverage register and reconcile duplicates or contradictory timestamps centrally. Use successive waves when concurrency is limited. If agents are unavailable, use separate manageable passes or fresh sessions with explicit handoffs, and disclose shared context.

Ask a separate reviewer to inspect the source-backed workload, alternative rules and actual run outputs without the author’s explanation. Have it check equal treatment of capacity, missing dependencies, unsupported timing and whether a preferred structure received easier assumptions. Repair material findings and rerun affected cases. If no independent reviewer is available, perform a separate check and state that limit.

Show what each structure would feel like

Deliver a side-by-side comparison against our agreed criteria, supported by a few vivid case replays: “This request changes hands here; under this structure this role can resolve it directly, but complex cases queue behind this specialist.” Include diagrams, ownership and decision rules, evidence references and an inspectable run log or model. Distinguish observed baseline results, calculated simulation outputs and qualitative judgments.

Explain where each structure works well, its bottleneck and the conditions under which your preference changes. Identify what actual evidence would resolve the most important uncertainty. If useful, describe a bounded pilot and what it would measure, without starting it. The finished result is a grounded comparison of how the same work travels through different structures; simulated reactions and outcomes remain explicitly simulated.

Done when

You can follow the same real work through the current team and the agreed alternatives, see how ownership and decision rules change the outcome, and inspect the evidence and simulation behind the comparison. The result identifies its strongest tradeoffs and uncertainties without representing simulated gains or employee reactions as observed facts.

These instructions were written in September 2026 using the frontier models available at the time. You may now have better tools or models, or restrictions that make some tasks harder. Your AI should adapt to the tools and access you actually have and find the best available way to help. Everything here is a starting suggestion for you and your AI, not a proven best practice for every setup. Feel free to rewrite any of it to better meet your needs.