Capability exploration

Find the strongest practical way to complete the work. Explore the combination of model, business context, tools, and execution environment before freezing the solution. A useful discovery can change the task people delegate, the product they use, or how much custom software they need.

Give the system meaningful work

Start with a representative assignment and a recognizable finished result: investigate an incident and restore the affected service, migrate a repository and pass its acceptance checks, or produce a research brief that resolves a decision. Identify what makes the work difficult and what an experienced person would inspect to accept it.

Keep room for a better outcome than the initial feature request. "Summarize our tickets" could become investigating recurring failures, reproducing one, and preparing a tested fix. Establish whether that broader assignment serves the user's objective; then explore the capability that would make it possible.

Discover the available building blocks

Inspect the host's tools, skills, files, applications, and authorized account surfaces. Follow promising capabilities through operator, administrator, and developer interfaces. An incumbent product may already provide the work surface, permissions, source relationships, or task lifecycle that a proposed new application would otherwise recreate.

Research current primary documentation where capability or fit remains uncertain. Check the model and the product or runtime exposing it: available tools, supported inputs, execution duration, background work, recovery, deployment locations, and data handling can differ. Verify the commercial or operational constraint that affects this choice, including licensing, quotas, and cost.

Investigate unfamiliar approaches when they could change the outcome. A workforce product, an extension to an enterprise application, a managed agent service, and an application with its own runtime solve different parts of the problem. Compare the plausible arrangements for this task. Widen the search while a consequential gap remains; stop when further candidates are unlikely to change the decision.

Test the whole configuration

Begin with a capable configuration suited to the difficult work and references that convey the intended result: business definitions, working examples, source code, executable acceptance checks, or a detailed design. Keep useful detail accessible as the task develops. This establishes a credible capability ceiling; then improve economics and operating fit while preserving the result that matters.

Let the system investigate, create, inspect its results, and revise its approach. When it stalls, identify the missing capability: can it run the application, inspect logs, query the relevant state, or exercise the receiving workflow? Improve that access or interface and retry the assignment. More instructions to verify work cannot replace a usable verification path.

Record the configuration and inspect both the delivered artifact and the resulting environment. Measure completion, quality, elapsed time, human repair, and cost at the level of accepted work. Use comparable tasks when comparing candidates. Repeat variable results and distinguish shortcomings in reasoning from missing context, weak tool descriptions, access failures, or runtime behavior.

When upgrading a model or runtime, also test a simpler arrangement. Fixed task splits, forced context resets, or repeated review loops may compensate for a limitation that has changed. Remove them when representative results support it, while retaining business requirements and enforced permissions. Test whether the new configuration can own a larger useful assignment as well as perform the old one faster.

Choose additional probes from the claim the design depends on. Test resumption if tasks cross sessions; exercise the receiving system if the value depends on an action; inspect editability if the deliverable is a working document. Keep simulated behavior and executed product behavior distinguishable.

Read the engineering migration probe when the question is whether a model and harness can own substantial work through a tested artifact and an interruption.

Turn observations into a choice

Describe the recommended arrangement as something a team can operate: where people work, what the agent completes, which systems supply context and receive actions, where progress persists, and who maintains the custom parts.

Choose managed or owned execution based on the responsibilities the workload requires. A managed runtime can supply lifecycle and execution facilities; an owned runtime can support unusual network, tool, or control requirements. Inspect the chosen service's current interfaces before assigning it either advantage. A capable employee product may already be sufficient.

Explain the discovery that changed the design, the material alternative, and the unresolved fact that could reverse the recommendation. Carry successful probes into the requested solution or implementation. Preserve useful artifacts and primary sources so the next team can reproduce the reasoning. Revisit the choice when the workload or available capabilities change; keep the selection method durable.