3.2.3. Actions, Connectors, and Parameters
💡 First Principle: Parameters are the contract between reasoning and procedure. Inputs declare what the agent must supply before the flow can run; outputs declare what the flow promises back. A well-typed contract lets the orchestrator gather the right values in conversation and lets the topic use the results downstream — no contract, no cooperation.
Inside the flow, connector actions do the reaching — the same 1,500+ connector ecosystem from Phase 2, invoked procedurally: create the record, send the message, update the row. Under generative orchestration, the description of the flow and its inputs guides when the orchestrator invokes it and what it asks the user for; from a topic, input values are mapped explicitly from variables, and output parameters land as topic variables for later nodes (a thread 3.3.5 completes). Typed inputs (text, number, boolean, dates) are what make that mapping safe in both directions.
Connections — the credentials behind each connector action — carry their own design weight. Flows run with configured connections, so decide deliberately as whom each action executes (the 3.1.1 question again, at flow granularity), and use connection references so the same flow rebinds cleanly across dev, test, and prod rather than hard-wiring credentials (Phase 4 formalizes this).
⚠️ Exam Trap: "The flow runs but the agent can't use its result" is an output-parameter problem — either no output declared or the topic isn't consuming it. Conversely, "the orchestrator invokes the flow without asking for the order number" points at a missing/undescribed required input.
Reflection Question: Design the parameter contract for a "book conference room" flow: what are the minimum typed inputs, what's the one output the conversation genuinely needs back, and what changes in each direction if you add "any available room" as an option?
