Agent Execution Model

Current project agents use a single project execution binding: api.

Supported project execution binding

{
  "execution": {
    "type": "api",
    "modelId": "quality"
  }
}

This means:

• the project uses one model from the global city model pool
• the project stores only the modelId
• provider details, credentials, and model names live globally

How runtime execution works

At a high level, startup and execution look like this:

1. read project config
2. resolve execution.modelId
3. resolve the final model from the global model pool
4. create session executors
5. combine static prompts, history, tools, and model into one execution context

That is the core runtime mental model:

project config + static prompts + session history + tools + active model

Why the project stores only modelId

This design gives clear advantages:

• multiple projects can share one model definition
• API keys do not need to be duplicated in every project
• switching project models becomes a one-field change

It also keeps platform operations and project operations separate:

• the platform owns model definitions
• the project owns model selection

Do CLI, channels, tasks, and SDK reuse the same execution core?

Yes.

Whether you enter through:

• city agent chat
• a chat channel
• a task run
• SDK Agent or RemoteAgent

the system still converges on the same underlying session and executor ideas.

How local SDK differs

Local SDK Agent lets application code explicitly pass:

• tools
• services
• a session-level model

That is the main difference:

• project runtime gets its model from downcity.json.execution.modelId
• local SDK sessions get their model through session.set({ model })

This difference is one of the most common first-time SDK pitfalls.

Continue with:

• Platform model pool
• SDK overview