When Names Become Prompts: Naming Conventions for OutSystems Workbench Agents

Have you noticed how “just a name and/or descriptions” in OutSystems can now completely change how your AI agent behaves?

For years, naming conventions were mostly about human readability and long‑term maintainability. As long as your colleagues understood what GetCustomerData did, you were fine.

With OutSystems Workbench and AI agents, that’s no longer true.

Today, action names, structure definitions, and descriptions are part of the runtime behavior of your application. They literally become a prompt surface for the AI model. A vague name is not just a style issue anymore; it’s a potential bug.

In this article, I’ll walk through a practical naming model for OutSystems Workbench:

• GRD — Grounding Data.
• AGD — Agent Data.
• SA — Service Action structures.
• Tools — Actions exposed to agents.
• Framework actions — AgentFlow, BuildMessages, GetGroundingData, LoadMemory .

You’ll see how they fit together, why names matter, and which rules to adopt so your agents behave predictably.

Why Naming Suddenly Matters So Much

When you create an agent in OutSystems, you assign:

• Action Callings — actions the agent can invoke (tools, in MCP terms).
• Expected structures — shapes of the data the model should produce.

The model doesn’t see your Service Studio diagrams. It sees:

• Action names and descriptions.

From this, it tries to infer:

• How to fill in input fields.
• How to validate and transform data.
• How to interpret grounding data.

So every time you rename an action or structure, or tweak a description, you’re not just refactoring. You’re changing the prompt.

That means:

Good naming → clearer prompts → better decisions.

Sloppy naming → ambiguous prompts → unpredictable behavior.

Let’s break down a concrete convention that aligns with how Workbench agents actually use your code.

1. Structures: GRD, AGD, and SA

In practice, I’ve landed on three main structure families:

• GRD — Grounding data for the model.
• AGD — Data the agent reads/writes via tools.
• SA — Service/API-facing structures, not used for agent context.

Each exists for a different purpose, and the AI treats them differently.

GRD — Grounding Data Structures

Goal: Give the model contextual information in a clean, model‑friendly way.

Prefix: GRD Example names:

• GRDCustomerSummary
• GRDTicketOverview
• GRDUserContextInput

Key rules:

Always use a dedicated GRD structures for grounding data. Don’t feed raw aggregates or external DTOs (data transfer objects) directly into prompts. Instead:

1. Create GRD_CustomerSummary action
2. Map only the fields the agent actually needs
3. Keep the structure stable over time
4. Field names are part of the prompt.

• They are included in the model input, and heavily influence interpretation:
• Good: CustomerName, IssueDescription, IsVipCustomer. - Bad: Name1, Desc, Flag

5. Field descriptions are not part of the prompt. They are for humans:

• Use them to help developers
• Don’t rely on them for model behavior — the AI never reads them in grounding data.

Be careful reusing GRD across agents. Only reuse a GRD structure if its meaning is truly invariant across agents. Otherwise:

1. Define a new GRD structure per agent context.
2. Avoid “one GRD to rule them all.”
3. Avoid serializing aggregates/external structures directly.
4. No GRDWhatever that mirrors your DB or API 1:1.
5. Prefer a minimal, purposeful GRD tailored to the agent’s needs.

In short, GRD is how you speak “context” to the model, using only names.

GRD Folder/Structures

1.2 AGD — Agent Data Structures

Goal: Shape what the agent produces and consumes through tools.

Prefix: AGD AGD structures represent:

• The model’s output (what it’s trying to produce)
• Tool inputs and outputs
• Sometimes, a blend of both is used along an execution flow

Example names:

• AGDCreateTicketInput
• AGDCreateTicketOutput
• AGDMeetingSummary

Key rules:

1. AGD is the agent’s working data model. When the agent calls tools, the inputs and outputs should be AGD structures.
2. **Names and descriptions both matter.

• *Names tell the model what this is
• Descriptions tell the model how to use it and what constraints apply*

3. Use descriptions for validation hints. For each attribute, specify intent and constraints, e.g.:

• "Mandatory. Short title for the issue. Max 200 characters."
• "Jira issue key (e.g., PROJ-123). Must exist in the system."
• "Must be a valid link"

4. The model will attempt to respect these rules.
5. But AGD validation is not back-end validation. Think of it like front‑end validation:

• It guides the model
• It does not replace real validations in your server actions or APIs

6. Keep AGD structures focused. One clear responsibility per structure is better than a “god” AGD with everything.

In other words, AGD is how you define what the model is allowed to say and do.

AGD Folders/Structures

1.3 SA — Service Action Structure

Goal: Clean API contracts for non‑agent consumers.

Prefix: SA Service Actions use SA structures and are not intended for agent contextualization. However, the practices described in this article remain valuable across all project and module types, from ODC to O11, as they promote consistency, maintainability, and architectural clarity.

Example names:

• SAUserProfileRequest
• SAUserProfileResponse
• SACreateTicketRequest

Key rules:

1. SA is for services, not prompts.
2. These structures are consumed by other modules or external systems
3. Do not expose GRD/AGD through Service Actions.
4. Internally, map SA ↔ GRD or AGD as needed.
5. **Treat SA naming like public API design.

• **Clear, behavior-focused names
• Stable contracts
• Backwards compatibility in mind

This separation keeps your “agent world” and “API world” cleanly decoupled.

2. Actions: Framework, GRD Actions, and Tools

Naming actions is just as important as naming structures. They drive:

• How you discover them in Service Studio.
• How Workbench filters them.
• How the agent decides what to call.

Let’s look at three key categories.

2.1 Framework Actions per Agent

OutSystems provides a core set of framework actions:

• AgentFlow
• BuildMessages
• GetGroundingData
• LoadMemory

Each has a clearly defined role in the agent lifecycle. But a single module can host multiple agents, so names must be unique and unambiguous.

Naming pattern:

• AgentFlow_[AgentName]
• BuildMessages_[AgentName]
• GetGroundingData_[AgentName]
• LoadMemory_[AgentName]

Example for an agent called SupportBot:

• AgentFlow_SupportBot
• BuildMessages_SupportBot
• GetGroundingData_SupportBot
• LoadMemory_SupportBot

Why this matters:

• It keeps your module navigable when you add more agents.
• It avoids collisions and confusion in configuration.

2.2 Grounding Data Actions (GRD Actions)

Fetching grounding data often involves multiple and different sources:

• Database tables.
• External APIs.
• Other modules.

To keep this manageable and predictable, use dedicated GRD actions per data source.

Example:

• GRD_GetCustomerById
• GRD_GetTicketsForCustomer
• GRD_GetUserContextFromSSO

Key rules:

1. One data source/responsibility per GRD action. Each action:

• Fetches from a given source.
• Maps the result into a GRD structure.

2. Output is always GRD. A GRD action should only output GRD structures. This keeps your pipeline clear:
3. Raw data → GRD actions → GRD* → Agent grounding.
4. Use consistent naming patterns. Examples:

• GRD_Get for a single fetch.
• GRD_List for collections.

This way, when you see GRD_GetIt’s obvious:

“This produces grounding data, not business logic output.”

2.3 Tools — Actions Assigned to the Agent

In MCP/Workbench terminology, tools are actions an agent is allowed to call. From the agent’s point of view:

Tools are its operational vocabulary.

Example tool names:

• CreateSupportTicket
• UpdateCustomerAddress
• SendSlackNotificationToChannel

Key rules:

1. Name tools by intent and target.
2. Good: Tool_CreateJiraIssueTool, Tool_CloseSupportTicketTool, Tool_SendCustomerSurveyEmailTool
3. Bad: DoAction, HandleStuff, ProcessData
4. Describe your action.
5. Tool input and output must be an AGD structure.
6. **Prefer multiple small tools over one giant one.

• Tool_CreateSupportTicket - Tool_AddCommentToTicket - **Tool_ChangeTicketPriority

7. Descriptions of the tools are sent to the agent context and must ensure a clear action purpose, what it accomplishes, and when to use.

Clearly describe the action’s purpose, what it accomplishes, and when to use it

This is where naming and description directly shape agent reasoning: the clearer the intent, the more accurate the tool selection. Additionally, from a maintainability perspective, when encountering an action prefixed with Tool_, it is immediately clear that it acts as a wrapper for an agent-invokable action.

3. Putting It All Together: An AI Contract

If you zoom out, these conventions form an AI contract:

• GRD – “Here is the world as context.”
• AGD – “Here is what you can read/write when doing work.”
• SA – “Here is the API facing the outside world.”
• GRD actions — “Here’s how to fetch and structure context.”
• Tools — “Here’s what you can do.”
• Framework actions — “Here’s how your agent lifecycle is orchestrated.”

And names/descriptions are not just there for humans anymore. They are how you talk to the model.

If you change:

• a GRD field name,
• an AGD description,
• a tool name or its description,

You are effectively changing the prompt.

That’s powerful — but also risky if done casually.

Actions and their structures

Closing Thoughts

The moment your OutSystems module starts hosting an AI agent, your naming conventions stop being “just style.” They become part of a live contract between your code and the model.

If you treat GRD, AGD, SA, tools, and framework actions as first‑class prompt elements, you’ll:

• Improve agent decision quality.
• Reduce weird, hard‑to‑debug behaviors.
• Make your modules more discoverable and maintainable for the humans on your team.

References:

https://success.outsystems.com/documentation/outsystems_developer_cloud/building_apps/build_ai_powered_apps/agentic_apps_in_odc/ai_agent_actions/