Build an agentic worker

• An identity and worker type
• Business-specific instructions
• A model and credential
• Extension tools and reusable flows
• Guardrails
• Short-term or long-term memory
• Knowledge bases
• Execution limits

Many Greentic solutions combine both. An agentic worker understands the request, while a deterministic flow performs the controlled business process.

Worker

ACME Support Process Router.

Purpose

Classify an open-text customer-service request and return structured routing data.

Called by

ACME Customer Service Main Menu.

Possible outcome

Route a late-delivery request to ACME Late Delivery Resolution.

Customer enters an open question
              ↓
Customer Service Main Menu flow
              ↓
ACME Support Process Router
              ↓
Structured intent result
              ↓
Deterministic resolution flow

• Confirm that the correct workspace is active.
• Define one specific responsibility for the worker.
• Decide what the worker must never do.
• Identify the expected input and output.
• Confirm that a suitable model credential is available.
• Identify any tools, flows or knowledge bases the worker requires.
• Decide whether the worker needs memory.
• Prepare representative test messages.
• Use fictional data during design and testing.

Enlarge

1. 1Open Designer Home.
2. 2Select New project.
3. 3Enter a clear project name.
4. 4Select Agentic Worker.
5. 5Review the project-type description.
6. 6Select Create.
7. 7Wait for Agentic Worker Studio to open.

The New Project dialog also offers other project types, including flows, playbooks and imports. This guide covers only Agentic Worker. SoRLa Studio is shown in the dialog as Coming soon.

Enlarge

Goal field

Describe what the worker should do, what it receives and what it should return.

Model selector

Select the model available for generating the initial worker configuration.

Example use cases

The interface provides starting ideas such as customer support, sales follow-up, help centre bot and customer onboarding.

Build my Agentic Worker

Generate the first worker configuration from the supplied description.

Create a worker called [name].

Its single responsibility is to [specific responsibility].

It receives:
- [input 1]
- [input 2]

It must return:
- [output 1]
- [output 2]

It may:
- [approved action]

It must not:
- [prohibited action]

When uncertain, it should:
- [clarification or escalation behaviour]

1. 1Describe one clear worker responsibility.
2. 2Include the expected inputs.
3. 3Include the expected output.
4. 4State important non-goals.
5. 5Explain what should happen when the request is ambiguous.
6. 6Select the generation model.
7. 7Select Build my Agentic Worker.
8. 8Review every generated setting in Composer.

Enlarge

Display name

The human-readable name shown to designers and operators.

Description

A concise explanation of the worker’s role.

Single-turn

Designed for focused interactions and everyday tasks. It can respond and use approved tools without running a long autonomous process.

Agent graph

Designed for multiple specialist agents working together, with one deciding which specialist handles the work.

Deep worker

Designed for longer, multi-step jobs that require planning and checking progress.

The available capabilities of each worker type may evolve. Use the descriptions shown in the current Designer interface as the source of truth.

Enlarge

Tone

An optional description of how the worker should communicate, for example warm, concise or professional. For a machine-facing router, tone may be irrelevant because the worker returns structured data rather than customer-facing prose.

Instructions

The main business-specific instruction document. The platform may add standard behaviour and operational controls around these instructions.

Opening message

A message shown when the worker begins a customer-facing conversation. For an internal process router invoked by a flow, leave this blank.

1. 1Role — state what the worker is.
2. 2Single responsibility — state exactly what it must accomplish.
3. 3Inputs — list the fields it receives.
4. 4Outputs — define the required response structure.
5. 5Allowed actions — state what it may do.
6. 6Prohibited actions — state what it must not do.
7. 7Ambiguity handling — explain when to ask a clarification question or return an uncertain result.
8. 8Escalation — state when human support or another controlled process is required.

Enlarge

Credential

Select a model credential made available to the workspace.

Provider

The AI provider associated with the selected credential.

Model

The exact model identifier used by the worker.

Temperature

Controls how consistently or creatively the model responds. For structured classification, use a relatively precise setting and test whether the same request produces stable output.

Maximum reply length

Limit the size of the worker’s response where a concise result is expected.

The provider, credential and model shown in the screenshot are examples. Do not treat them as required Greentic defaults.

Enlarge

Extension tools

Installed extensions expose approved capabilities to the worker. The interface provides Add extension, search, a category filter, a description of each extension and an Add action.

Flow as tool

An existing flow can be made available as a callable tool where that architecture is appropriate.

1. 1Open the Tools tab.
2. 2Decide whether the worker genuinely requires a tool.
3. 3Select Add extension or Add flow as tool.
4. 4Search for the required capability.
5. 5Review its description.
6. 6Add only the required capability.
7. 7Update the Behaviour instructions to explain when it may be used.
8. 8Test successful, failed and ambiguous cases.

Enlarge

• Guardrails can be suggested by AI.
• A suggested guardrail can be removed.
• Add guardrail opens the available guardrail choices.
• The interface shows whether the underlying protection is installed.
• A selected guardrail marked Not installed will not run.

The options visible in this release include PII masking, a profanity filter, a secret-leak guard and a topic or scope guard. The list shown in the interface is not permanent or exhaustive.

1. 1Review the worker’s exposure to untrusted input.
2. 2Open Guardrails.
3. 3Review any AI-suggested controls.
4. 4Add only the controls relevant to the use case.
5. 5Check the installation status.
6. 6Contact the partnership or platform administrator when a required capability is not installed.
7. 7Test the guardrail with safe fictional input.
8. 8Confirm that legitimate requests still pass.

Enlarge

Short-term memory

Used when the worker needs context between messages within an active interaction.

Long-term memory

Used when the solution requires information to persist beyond the immediate interaction, according to the selected provider’s configuration.

Provider controls

Each memory type includes an enable or disable toggle, provider selection, Configure and Remove.

Exact retention, storage and retrieval behaviour depends on the selected memory provider and its configuration.

Enlarge

Light

Best suited to simple lookups, focused classification and short replies with limited back-and-forth.

Standard

The default choice for typical conversations that may require a small number of tool calls.

Heavy

Intended for longer multi-step research or investigation that requires more extensive work.

Use the current interface descriptions as guidance. Test the worker rather than assuming a higher limit will automatically improve it. Composer may recommend a limit and include a reason; designers can remove the suggestion and select another level. The selected limit should match the worker’s actual responsibility.

• Policies
• Product information
• Procedures
• Support content
• Internal documentation

Enlarge

• The user enters an open customer request.
• The worker detects a likely late-delivery intent.
• The response includes structured fields.
• The result identifies the deterministic process intended to handle the request.
• The test panel includes Reset chat for starting a clean test.

The exact fields in the screenshot are specific to this demo and may include status, detected intent, confidence, extracted values, locale, a clarification question, possible intents, the called process and escalation indicators. Greentic does not automatically create or validate this exact schema for every worker.

1. 1Open the Composer test panel.
2. 2Reset the chat before testing an independent scenario.
3. 3Enter a representative request.
4. 4Confirm that the worker identifies the correct intent.
5. 5Confirm that required entities are extracted.
6. 6Confirm that uncertain requests produce the expected clarification behaviour.
7. 7Confirm that prohibited actions are not attempted.
8. 8Confirm that the output matches the downstream flow’s expected structure.
9. 9Repeat the same request with alternative wording.
10. 10Test at least one clearly unrelated request.
11. 11Test a failure or missing-information case.
12. 12Correct the instructions or configuration and test again.

• The worker has one clear responsibility.
• The display name and description are meaningful.
• The worker type matches the task.
• Behaviour instructions define inputs, outputs and non-goals.
• The opening message is appropriate for how the worker is invoked.
• The required model credential is selected.
• Temperature and response length match the use case.
• Only required tools or flows are attached.
• Required guardrails are installed, not merely selected.
• Memory is enabled only when needed.
• The execution limit matches the complexity of the task.
• Representative tests produce the expected result.
• Ambiguous and unsupported requests follow the approved fallback.
• Machine-facing output matches the downstream contract.
• No real customer data was used during testing.