DESIGNER GUIDE

Use models, tools and connected capabilities

Select configured AI models, add controlled tools to workers and flows and connect the resources a solution needs without exposing unnecessary capabilities.

Solution designer15–20 minutes

Scope: Agentic Worker, Flow project and deployment environment

Administrators configure. Designers select.

Provider credentials, extensions, MCP servers and other shared resources are configured through tenant administration. Designer exposes the resources available to the active workspace so solution designers can use them in workers, flows and environments.

How a capability reaches a solution

Anything a designer can select was made available further upstream.

Tenant administration
        ↓
Configured providers and capabilities
        ↓
Workspace availability
        ↓
Worker or Flow selection
        ↓
Deployment environment
Do not place credentials in project contentNever put provider secrets, OAuth tokens, API keys or registry credentials inside behaviour instructions, flow prompts, variables, knowledge documents or test messages.

Integration concepts

Credential
A configured connection that allows a supported model or provider to be selected.
Provider
The external or local service supplying the model or capability.
Model
The exact AI model used by a worker or bounded language step.
Extension tool
A packaged capability installed and exposed to the workspace.
Flow as tool
A reusable Greentic flow made available to an Agentic Worker.
Built-in step
A process capability supplied directly by Designer.
Extension step
A process step supplied by an installed extension.
MCP capability
A tool exposed through an approved Model Context Protocol connection.
Deployment resource
A worker, provider, capability or channel added to an environment.

Responsibilities

Configuration sits with administration. Selection and design sit with the solution designer.

Integration responsibilities
TaskPartnership or workspace administratorSolution designer
Add provider credentialsYesNo
Control tenant access and rolesYesNo
Install or configure extensionsYesNo
Connect MCP serversYesNo
Register component toolsYesNo
Select an available modelNoYes
Add an available extension to a workerNoYes
Add a reusable flow as a toolNoYes
Add supported steps to a FlowNoYes
Select a published Agentic Worker in a FlowNoYes
Add resources to a deployment environmentAccording to workspace permissionsAccording to workspace permissions

Related guides: Admin AI and tools, Admin Guardrails, Agentic workers, Flows and Publishing and deployment.

On this page

Before you begin

Decide the minimum capability set before opening a worker or flow.

  • Confirm that the correct workspace is active.
  • Define what the solution needs to accomplish.
  • Identify the minimum model and tool set required.
  • Confirm that shared resources are available to the workspace.
  • Verify that referenced workers or flows have been published where required.
  • Define the input and output contract for every tool call.
  • Prepare safe fictional test values.
  • Know the approved fallback when a connected capability is unavailable.
Start without a toolAdd a model or tool only when the process genuinely requires it. A deterministic flow using embedded demo data may need no external integration at all.

1. Select a configured model

The Model tab connects a worker to a credential, a provider and one exact model.

Select a credential, provider and model made available to the workspace.
Credential
The configured connection available to the workspace.
Provider
The service associated with the selected credential.
Model
The exact model identifier used by the worker.
Temperature
Controls how precise or varied responses may be.
Maximum reply length
Limits the size of the worker’s output where a concise answer is required.
The values shown are examplesThe provider, credential and model in the screenshot are demonstration values. They are not mandatory Greentic defaults.
  1. 1Open the worker’s Model tab.
  2. 2Select an available credential.
  3. 3Confirm the provider.
  4. 4Select the intended model.
  5. 5Set response variability appropriate to the use case.
  6. 6Set a maximum reply length where useful.
  7. 7Save the worker.
  8. 8Test representative requests.
  9. 9Repeat tests to confirm sufficient stability.
Match the model to the taskA structured intent classifier benefits from precise, stable responses. A broader content assistant may allow more variation.
Do not solve missing credentials inside the workerWhen the credential list does not contain the required provider, ask the administrator to configure and expose it correctly.

2. Add extension tools

Extensions give a worker the ability to act, within the boundary you define.

The Tools tab lets a worker use installed extensions or another Flow as a controlled tool.
Add extension
Opens the list of available extensions.
Search
Finds an extension by name.
Category filtering
Narrows the list to one kind of capability.
Extension name and description
Explains what the capability does before you add it.
Add
Makes the capability available to the worker.
  1. 1Open the worker’s Tools tab.
  2. 2Select Add extension.
  3. 3Search for the required capability.
  4. 4Review its description.
  5. 5Confirm that the capability matches the worker’s responsibility.
  6. 6Select Add.
  7. 7Update the Behaviour instructions to explain when it may be used.
  8. 8Test the intended action.
  9. 9Test unavailable, failed and unsupported cases.
Availability does not define intentAdding a tool makes it available. The Behaviour instructions still need to explain when the worker may use it, which inputs it should supply, which result it should expect and what it should do when the tool fails.
Do not add tools “just in case”Every tool increases the range of actions the worker may attempt. Keep the tool set as small as possible.

3. Add another Flow as a tool

Business actions belong in a deterministic Flow, not in the worker’s judgement.

  • Add flow as tool makes an approved reusable Flow available to the worker.
  • Use this when the worker needs to invoke a controlled business capability.
  • The Flow should own deterministic validations, approvals and outcomes.
  • The worker should know when it is allowed to call the Flow.
  • The worker and Flow must agree on a stable input and output contract.
Agentic Worker
      ↓
Chooses an approved Flow tool
      ↓
Passes structured input
      ↓
Deterministic Flow executes
      ↓
Returns controlled result
ExampleA customer-support worker may call a Late Delivery Resolution Flow after identifying a late-delivery request. The Flow — not the worker — should decide what information to collect and which resolution options are permitted.
Prefer a controlled Flow for business actionsUse a Flow as the boundary around actions involving validation, decisions, approvals, transactions, compliance or customer commitments.

The Flow must be available to the current workspace and exposed through the controls provided by Designer.

4. Use built-in and extension steps

Flows reach connected capabilities through steps rather than through worker judgement.

Flows can combine built-in process steps with capabilities supplied by installed extensions.
Steps
Built-in capabilities supplied by Designer.
Extension steps
Additional step types supplied by installed extensions.
Steps with an integration role
StepIntegration role
Agentic WorkerInvoke a published worker
Go to FlowReuse another deterministic process
HTTP CallCall an approved web endpoint
LLM ChatUse a configured model for a bounded language task
MCPInvoke an approved MCP capability
Human ApprovalConnect a process to the runtime approval system
Card RenderPresent or collect structured user data
Conditional BranchRoute using explicit values returned by another step
Use the most controlled step that fitsUse Conditional Branch for explicit rules, Agentic Worker or LLM Chat for interpretation, Go to Flow for reusable business processes, and HTTP or MCP only for approved connected capabilities.
A connected capability can failEvery HTTP, MCP, model or extension-dependent route should have a controlled failure or fallback path.

5. Select an Agentic Worker inside a Flow

The Agentic Worker step is the controlled boundary between deterministic process and interpretation.

The Agentic Worker step references an available worker and controls whether the interaction remains conversational.
Step name
Give the process step a business-focused name.
Agent
Select the Agentic Worker the Flow should invoke.
Conversational
Off: receive one reply and continue the deterministic Flow. On: continue the worker conversation until it ends, then continue the Flow.
  1. 1Add an Agentic Worker step.
  2. 2Select the step.
  3. 3Enter a meaningful step name.
  4. 4Select the required worker.
  5. 5Decide whether the interaction should be one response or conversational.
  6. 6Pass only the required input.
  7. 7Connect the output to a controlled next step.
  8. 8Test the worker directly.
  9. 9Test it again through the Flow.
Use single-response mode for routingA worker performing intent classification should normally return one structured result so the deterministic Flow can continue.
When the required worker is not in the selectorConfirm the correct workspace, confirm that the worker has been published locally where required, confirm that the current user can access it and confirm that the project reference has not changed.

6. Add resources to a deployment environment

An environment is where channels, workers, providers and capabilities are connected.

The deployment environment brings together channels, workers, providers and approved capabilities.
Channel
The place through which users or systems reach the solution.
Worker
The worker that responds through the channel.
Provider
A configured provider resource required by the environment.
Agentic Worker
An available worker added to the environment design.
Capability
An approved supporting capability.
Wiring assistant
A control intended to help connect environment resources.
Deploy environment
Starts the deployment process after the environment has been configured.
Channel
   ↓
Worker
   ↓
Model provider
   ↓
Approved tools and capabilities
   ↓
Deployed environment
  1. 1Open Deploy.
  2. 2Open the intended environment.
  3. 3Add the required channel.
  4. 4Add the worker.
  5. 5Add the required provider.
  6. 6Add only the capabilities the solution needs.
  7. 7Connect the resources using the current environment controls.
  8. 8Review the wiring.
  9. 9Use the Wiring assistant where appropriate.
  10. 10Deploy first to a safe non-production environment.
  11. 11Run a controlled post-deployment test.
The screenshot shows an empty environment onlyChannel forms, provider forms, wiring diagrams, deployment dialogs and success statuses are not shown here. Follow the Publishing and deployment guide for the release sequence.

7. Apply least privilege

Give each solution the smallest capability set that still delivers the outcome.

Least-privilege design
ResourceRestrict
ModelSelect only the model needed for the worker
ExtensionAdd only the capabilities required by the use case
Flow as toolExpose only approved deterministic processes
HTTP or MCPUse only approved endpoints and operations
KnowledgeAttach only relevant knowledge bases
MemoryEnable only when conversational continuity is required
GuardrailConfirm that required protections are installed and operational
Deployment environmentAdd only the channels, workers and capabilities required for that environment
Capability access should follow the worker’s responsibilityA routing worker may need no external tool. A delivery-status worker may need one order lookup. A broad collection of unrelated capabilities makes behaviour harder to predict, test and audit.
Never pass secrets through ordinary inputsCredentials belong in the platform’s secure administrative configuration, not in prompts, behaviour instructions, flow variables, cards, knowledge documents, test messages or logs copied into support tickets.

8. Test connected capabilities

Test the failure paths as deliberately as the successful ones.

Integration test matrix
ScenarioExpected behaviour
Required capability availableThe correct tool or Flow is invoked
Capability unavailableThe solution follows the approved fallback
Invalid inputThe call is not made or returns controlled validation
Empty resultThe worker or Flow explains the approved next step
Tool failureThe process does not invent success
Wrong tool requestThe worker does not call an unrelated capability
Repeated requestThe action is not duplicated when that would be unsafe
Sensitive actionHuman approval occurs before execution where required
  1. 1Test the worker without the connected capability.
  2. 2Test the normal successful call.
  3. 3Test missing required input.
  4. 4Test an invalid value.
  5. 5Test a simulated unavailable result where possible.
  6. 6Confirm the fallback path.
  7. 7Confirm that the user is not shown raw technical errors.
  8. 8Confirm that the worker does not invent a successful outcome.
  9. 9Retest the complete Flow.
  10. 10Repeat the test after deployment.
A tool call is not the same as a successful business outcomeThe solution must inspect the returned result and continue through a controlled path.

Integration review checklist

Complete this before publishing or deploying a connected solution.

  • The correct workspace is active.
  • The selected model is appropriate for the task.
  • The required credential is available.
  • No credentials were placed in project content.
  • Only required tools are attached.
  • Behaviour instructions explain when each tool may be used.
  • Every tool has a defined input and expected result.
  • Reusable business actions are encapsulated in deterministic Flows.
  • Agentic Worker steps reference the intended worker.
  • Conversational mode matches the use case.
  • HTTP and MCP routes have controlled failure paths.
  • Required knowledge bases are attached separately.
  • Required guardrails are installed and operational.
  • Deployment environments contain only the required resources.
  • Successful and failed capability calls have been tested.
  • Post-deployment testing has been completed.

Next steps

Integration troubleshooting

Most integration problems are availability, workspace or contract issues.

Integration troubleshooting
ProblemLikely causeAction
A model credential is missingThe provider is not configured or not exposed to the workspaceContact the workspace or partnership administrator
The wrong model is being usedAn unintended credential or model was selectedReview the worker Model tab
An extension is missingIt is not installed or available to the workspaceAsk the administrator to review Extensions
A Flow cannot be added as a toolIt is unavailable, unpublished or in another workspaceConfirm the project and publication state
A worker does not appear in a Flow stepIt has not been published locally or the workspace is wrongPublish the worker and confirm the workspace
The worker calls an unrelated toolToo many tools are attached or instructions are unclearRemove unnecessary tools and strengthen usage rules
A tool receives the wrong valueInput mapping or field naming is inconsistentReview the worker contract and Flow variables
A capability returns no resultThe resource is unavailable or the request is invalidFollow the approved fallback and review configuration
A tool failure is presented as successThe process does not inspect the returned statusAdd a controlled decision after the call
An MCP or HTTP option is unavailableThe tenant-level resource is not configuredReview the Admin AI and tools configuration
The deployment environment is incompleteRequired channel, worker, provider or capability is missingAdd and connect the required resources
An integration works in Designer but not after deploymentThe environment does not include the same supporting resourcesCompare project dependencies with environment wiring
A secret appears in a prompt or variableCredentials were handled through an unsafe fieldRemove and rotate the credential, then use secure administration
Back to Designer Guides