# Coded Agents in Flow Projects (Sibling Folder) A coded agent can live as a sibling folder to a flow project inside the same solution. The flow references it via `uipath.core.agent.` with `section: "In this solution"`. The flow's `uip maestro flow registry list --local` discovers the agent by reading `resources/solution_folder/process/agent/.json`, written by `uip solution projects add`. For the published-agent path (deployed standalone via `uip codedagent deploy`), see [coded/flow-integration.md § Pattern 2](flow-integration.md#pattern-2-published-coded-agent). ## Sibling Folder Structure The `` is the local UUID minted by `uip solution projects add` — stable the moment the agent joins the solution. ``` / ├── .uipx ├── resources/ # created and maintained by `uip solution projects add` │ └── solution_folder/ │ ├── process/agent/.json # holds the `resource.key` UUID │ └── package/.json ├── / │ ├── .flow │ └── project.uiproj └── / ├── main.py # agent entrypoint ├── pyproject.toml # Python project config ├── uipath.json # UiPath project config ├── entry-points.json # generated by `uip codedagent init` ├── bindings.json # runtime bindings ├── main.mermaid # generated graph diagram ├── project.uiproj # Studio Web project metadata ├── .env # environment variables ├── .uipath/ │ └── telemetry.json # telemetry config └── .venv/ # local virtualenv (created by `uv sync`) ``` ### Key differences from a published coded agent - **`resource.key`** is minted locally at `uip solution projects add` time, not by Orchestrator at `uip codedagent deploy` time - **No `codedagent deploy`** — the agent ships inside the solution package - **Registry discovery is `--local`** (reads `resources/solution_folder/process/` files); no login or `registry pull` required - **`model.section`** is `"In this solution"` ## Scaffolding the Sibling-Folder Coded Agent The full end-to-end workflow (solution init → flow scaffold → agent scaffold → register → wire → validate) is owned by [`quickstart.md` § Scenario 2](quickstart.md#quick-start-scenario-2--in-solution-coded-agent-in-a-flow). This file covers the agent-side detail of step 3 (scaffold) and step 5 (registration) in finer detail; the canonical sequence stays in the quickstart so it remains executable in one pass. If the solution and flow project don't yet exist, run `uip solution init ""` and then `uip maestro flow init ""` from inside the solution **before** the steps below — those calls are the start of Scenario 2. 1. From the solution directory, create the agent folder and scaffold inside it: ```bash mkdir cd uv venv --python 3.13 source .venv/bin/activate # .venv/Scripts/activate on Windows uv pip install # e.g. uipath for Coded Function uip codedagent setup --force uip codedagent new uv sync ``` For a simple stub with no LLM call, use the Coded Function framework (`uipath` package). This avoids downloading the full LangGraph or LlamaIndex stack and keeps the setup fast. 2. Implement `main.py`. Use lazy LLM initialization (create clients inside functions, never at module level). 3. Generate entry points: ```bash uip codedagent init ``` 4. Register the agent in the solution — **this is the step that mints the `resource.key`** the flow will reference: ```bash cd uip solution projects add .uipx --output json ``` After this command, `resources/solution_folder/process/agent/.json` holds the `resource.key` UUID. ### Flow Discovery From inside the flow project directory, the agent is discoverable via the in-solution registry. The `--local` flag tells the registry commands to walk up from CWD to find a `.uipx`, read the `resources/solution_folder/process/` files written by step 4, and surface every sibling project as a discoverable node type — all offline, without a tenant registry round-trip: ```bash # list every in-solution node type (all sibling projects) uip maestro flow registry list --local --output json # fetch the full manifest for the coded agent uip maestro flow registry get "uipath.core.agent." --local --output json ``` The second command's `Data.Node` object is what the flow skill pastes into the flow's `definitions[]`. For the node instance shape and top-level `bindings[]` entries, see the uipath-maestro-flow skill agent-plugin reference (In-solution variant). Without `--local`, `registry list`/`get` query the tenant registry (Orchestrator-published resources only) and will not surface the sibling project. ## Wiring the Agent's Inputs One `inputs.` entry per property in the agent's input schema (`entry-points.json`, mirrored in the definition's `inputDefinition.properties`). Two valid value shapes, same binding: ```json "inputs": { "": { "type": "jsExpression", "expression": "$vars..output.", "fieldType": "" } } ``` - `jsExpression` — bare `$vars...` expression, no `=js:` prefix. Upstream values read as `$vars..output.`; flow globals as `$vars.`. - `literal` — text template; static text mixable with `{{ }}` interpolations: `{ "type": "literal", "expression": "{{ $vars..output. }}", "fieldType": "" }`. - `` is the property's JSON-schema type from the agent's input schema (e.g. `string`, `boolean`, `number`) — read it from there, do not invent it. NEVER a plain `"=js:..."` string value — it ships as a literal string to the agent activity and fails at runtime with `Cannot find name ''`. Complete worked example (trigger → agent → end): uipath-maestro-flow skill, agent-plugin reference § Wiring Inputs. Input-only rule. Mapping the agent's output back to a flow-level global on an End node DOES use `=js:` — see [variables-and-expressions.md § Variable Updates](../../../uipath-maestro-flow/references/shared/variables-and-expressions.md#variable-updates-variableupdates).