Suppose you request a file task in your general-purpose conversation: check a project's documentation against its example code, identify inconsistencies, and propose revisions. You may want Codex or Claude Agent for this task, or prefer the current execution path. The value of choosing is bringing suitable execution capabilities to the work without reorganizing the entire assignment for a change of tools.
Why We Are Building Teloa argues that models and harnesses can evolve while users retain their team's accumulated work. For this example, that starts with retaining the original question: what to check, which differences matter, and who will assess the result.
Teloa currently uses DeepSeek Harness (DSH) for the main conversation and native external child execution to integrate Codex and Claude Agent. The goal remains in the parent conversation, a suitable execution path handles the work, and its result returns to contribute to the same deliverable.
First distinguish a different model from a different way of working
| Choice | What it mainly changes | What it aims to address in this documentation check |
|---|---|---|
| Change the model | Reasoning, expression, call protocols, and usage | Analyze the same material differently and assess whether the differences support a conclusion |
| Change the execution engine | Tools, the working environment, waits, and result return | Adopt another familiar way of working with code and file tools |
Whether switching is worthwhile depends on the task's needs. Putting both choices into one model list can hide differences in tools and execution methods behind their names.
Separating the two makes the choice more precise. Changing a research role's model should not also change which clients it handles or which material it uses. Choosing an external engine for one general-purpose task should not be treated as permanently rebuilding the main conversation. The user changes the execution arrangement; the original question still needs an answer.
Delegate the check while retaining the question
Continue with the example. The user requests a documentation consistency check. External child work might return a list of differences, supporting evidence, or unfinished parts. A successful execution result alone does not establish that the documentation is accurate or that the proposed changes have been adopted.
Keeping the goal in the parent conversation leaves a place to assess that material. An example may run successfully while supporting different parameters from those described; that remains part of the original check. A file that could not be obtained leaves a gap, which an apparently complete list must not hide.
On the current path, external child execution returns its state and results to the parent conversation. The request, follow-up questions, and result integration can therefore stay within the same piece of work. Users do not have to relay a result stripped of its origins to another assistant.
This preserves a practical benefit of choice: users can use different engines' tools and working methods without abandoning requirements they have already established. Teloa takes on the cost of handling real lifecycle differences so that starting, waiting, returning, and stopping still correspond to this work. Wrapping several interfaces in identical buttons is insufficient.
Which work can currently use an external engine?
A shared entry point cannot give different execution environments identical safeguards. Work in roles, businesses, and groups currently has managed boundaries for material and tools. External providers cannot fully inherit those conditions, so that work stays on its existing managed path.
External child execution is available on the supported paths for the user's general-purpose conversation and independent general-purpose work. It requires a safety mode that allows manual approval and separate execution permission for this invocation. Independent work must also be bound to its original run and current authorization. Launch checks include whether the engine is loaded and whether the original instruction and session conditions remain valid.
The permission needs particular care: Teloa's file boundaries and per-action approvals are not forwarded to the external engine; execution uses the engine's own native permissions. The working directory is a condition that must be explicit for this invocation. It does not establish file isolation equivalent to Teloa's. Users need to assess the file task against the permission actually presented.
Engine selection also follows the owner's direct instruction. Material mentioning Codex is not a request to use it. If the owner explicitly selects an engine and it is unavailable, another must not be silently substituted. Selection, availability, and execution permission need to hold for this task; a brand name cannot stand in for them.
The original deliverable remains the measure
Return to the documentation check. After child work returns, the differences still need supporting evidence, unchecked files need to be identified, and proposed revisions need to address the original problem. The user decides which suggestions to adopt and can make further requests about that specific material.
This gives open choice a more practical measure than the number of supported engines: after a different execution path is used, can the person still understand what they requested, what they received, and what needs their judgment next? An engine being suitable for the tools involved does not exempt its output from review. An unsuitable result does not require discarding the goal and starting over.
The next check of the same project may use different tools or models. What deserves to remain is the established requirement, a result that can be traced, and the differences still unresolved. Execution choice should help users continue addressing those questions without reconstructing the work's origins every time the tools change.