engifoundry-exec

EngiFoundry Exec

Execution Selection

This section applies only to the controlling Agent arranging execution. A session that received engifoundry.executor-task/v1 is already the Executor Worker; the protocol is a terminal routing fact. It skips Executor selection and invocation, must not compare or infer its model identity, executes only the referenced Job, and returns one engifoundry.executor-handback/v1 object. It must never invoke or select another Executor.

The controlling Agent reads ./engifoundry.config.json, the project-owned workspace guide, the complete Executor and Workflow config files, contracts.md, and executor-task.template.json in full. Follow the Executor config's schemaRef and read that complete schema before selecting or invoking an Executor. Do not extract only executor, command, model, or usage; the surrounding fields and every declared Gate remain binding. Then read the Phase, PAK, and Job contracts before acting.

Compare only the active model with the configured Executor model; CLI identity and executorId do not decide execution ownership. When the configuration pins the same canonical model as the active model, the controlling Agent directly executes eligible Jobs in the current session without invoking an Executor Worker or producing a Worker handback. This is normal configured execution, not fallback or self-approval. The controlling Agent still applies all Exec discipline, evidence, Review, approval, and completion rules.

When the pinned models differ, invoke the configured Executor through its verified CLI usage, including the configured canonical model argument. A cli-default selection makes no model identity promise and therefore has no same-model fast path; invoke its configured CLI. Once the invocation accepts the task, model selection is settled by the controlling session and the receiving Worker executes it. Natural-language model self-identification is not trusted evidence: a model may know only its family name rather than the configured product alias.