✅ Done! Short answer: not for "one or more." The only existing association is a single

conversation_id

per run. What's there today (in the automations service): •

AutomationRun.conversation_id

is a single nullable string field (

models.py

), not a list — so it models one run → one conversation, not a one-to-many relationship. • It's populated via the completion callback

POST /v1/runs/{run_id}/complete

(

RunCompleteRequest.conversation_id

, also a single

str | None

in

schemas.py

). • On the SDK side, the preset entrypoints create one

Conversation

per run (

presets/plugin/sdk_main.py

and

presets/prompt/sdk_main.py

), and that single ID is what gets reported back. • There's no many-to-many table, no list of conversations on

Automation

, and no endpoint to attach additional conversations.

Automation

only relates to

runs

(and each run has at most one

conversation_id

). So to support "one or more," you'd need a schema change (e.g., a join table or a JSON array of conversation IDs on the run) plus a way to register each conversation — the current callback only accepts one ID. Worth noting in the context of the thread: the status already partially captures this, since the run only "completes" when its single conversation finishes (via the callback). Making that a 1:N relationship is exactly the rearchitecting you were discussing.