# Inside SAP Joule Studio: Building Skills to consume Actions > Source: > Published: 2026-07-10 12:01:01+00:00 💡This is Part 3 of a comprehensive series on building enterprise AI agents. If Actions represent the integration layer, Skills represent the operational intelligence layer. This is where the agent learns what it is capable of doing. One of the biggest misconceptions around AI agents is that the language model itself performs all of the work. In reality, enterprise agents are often closer to orchestrators than knowledge systems. Their primary responsibility is deciding which capability to invoke, gathering the required inputs, executing the operation, and presenting the result. In SAP Joule Studio, Skills are the mechanism that makes this possible. A Skill defines: Conceptually, the flow is simple. **User Request → Skill Trigger → Action Execution → Process Response → Return Result** The implementation, however, contains several nuances that are not immediately obvious. **Creating the First Skill** For the initial implementation, I created separate Skills corresponding to major business capabilities. Examples included: Portfolio overview, Customer analysis, Alert investigation, Product listing, Alert acknowledgement, Consumption analysis Each Skill was responsible for a single business function. This design choice turned out to be important because it gave Joule clear boundaries when deciding which capability to invoke. Rather than forcing the model to choose among dozens of Actions directly, it only needed to determine which Skill best matched the user’s intent. The resulting architecture looked like: **Agent → Skill → Action → API** This separation significantly improved predictability. **The End Trigger Gotcha** This was probably the most frustrating issue encountered during the entire project. Everything appeared configured correctly. The Action executed successfully. The API returned data. The output variable contained the expected value. Yet the Agent received nothing. The result was either: ``` null ``` or a cryptic error such as: ``` EL1008E: Property or field cannot be found on object of type ‘Map’ ``` At first glance, this looks like a response mapping issue. In reality, the problem is much simpler. “The output variable must be explicitly bound to the End node.” Many developers naturally assume that defining an output variable and populating it during execution is sufficient. It is not. The variable must also be exposed through the End trigger. ``` Incorrect Configuration: Action Result → Output Variable Correct Configuration: Action Result → Output Variable → End Node Output ``` Without the final binding step, the Skill completes successfully but** returns nothing to the Agent.** This single issue accounted for several hours of debugging. **Understanding the Formula Editor** The Formula Editor is where Skill outputs are transformed and mapped. Coming from a traditional programming background, I initially expected something resembling a lightweight scripting language. It is not. The Formula Editor behaves more like a constrained expression builder. That distinction becomes important very quickly. Several rules emerged through experimentation. **Rule 1: Never Type Variable Names Manually** When viewing available data, SAP generates internal identifiers. These often look something like: iii__3.result or iii__7.output The temptation is to type them directly. Avoid doing this. “Always select variables from the Data Panel.” The generated identifiers can change, and manual references frequently lead to deployment errors. **Rule 2: String Handling Is Extremely Important** A large portion of Skill development eventually became a string-management exercise. For example: “Customer Name: “ + CustomerName works correctly. However: “Total Alerts: “ + AlertCount can fail if AlertCount is treated as a numeric value. This is the reason the API was redesigned to return strings for almost everything. Doing so dramatically reduced transformation complexity inside Skills. **Rule 3: Keep Transformations Minimal** Initially I attempted to construct sophisticated responses inside Skills. The result was a growing collection of formulas, concatenations, and mappings. Over time it became clear that the simpler architecture was to push formatting responsibility back into the API. Instead of: API → Raw Data → Complex Formula Logic → Final Output Use: API → Preformatted Result → Direct Output The API becomes slightly more responsible, but **Skill complexity decreases** dramatically. For agent-oriented workflows, this tradeoff is usually worthwhile. **Conditional Logic: Where Things Become Tricky** At some point I attempted to create a “universal” Skill capable of routing requests to multiple Actions based on conditions. The idea seemed elegant. A single Skill. Multiple branches. Different API calls depending on user intent. Conceptually: If Type = Alerts → Call Alert API If Type = Products → Call Product API If Type = Customers → Call Customer API In practice, this introduced a subtle problem. Variables generated inside conditional branches are not always easily accessible from a shared End node. As workflows become more complex, output resolution becomes increasingly fragile. The result is often unexpected null values despite successful branch execution. After multiple iterations, I adopted a simpler approach. Instead of routing inside the Skill,** route inside the API.** For example: ``` GET /browse?category=alertsGET /browse?category=productsGET /browse?category=customers ``` The Skill remains simple. The backend handles the complexity. This design proved significantly easier to maintain. **Skill Inputs Are More Important Than They Look** One of the most underrated features in Joule Studio is the description field attached to Skill inputs. Most developers treat descriptions as documentation. The **agent treats them as instructions.** That difference is critical. Consider the following input definition: Weak Description Customer ID The agent has very little context. If a user says: Show details for customer 12345, the agent may pass: 12345 directly to the API. If the backend expects: CUST_12345 the request fails. A better description would be: “Customer ID in format CUST_XXXXX. When the user provides only digits, automatically prepend CUST_.” Now the agent understands the transformation. This small change dramatically improved request accuracy. In many cases, **improving Skill descriptions produced better results than modifying prompts**. That observation highlights an important reality of enterprise AI systems. The quality of the interface often matters more than the sophistication of the model. A well-described capability reduces ambiguity before the model ever begins reasoning. **What’s Next? Moving Up to the Agent Layer** Building reliable enterprise AI is rarely a battle of model sophistication; it is a battle of system integration. By treating Skills as strict, predictable wrappers around your backend APIs, you eliminate the unpredictability that usually breaks LLM-driven workflows. But establishing a rock-solid capability layer is only half the problem. Once your Skills are securely connected, you face an entirely different challenge: **Trust.** How do you ensure the Agent reliably selects the right Skill, formats data without breaking downstream contracts, and avoids dangerous hallucinations when things go wrong? In the next article, we’ll move up the stack to focus entirely on configuring the Agent, writing bulletproof operational guardrails, and managing state across complex, multi-step workflows. 🚀 Part 4 will be live in a few days. Make sure to follow my profile so you get notified the second it drops! [Inside SAP Joule Studio: Building Skills to consume Actions](https://pub.towardsai.net/inside-sap-joule-studio-building-skills-to-consume-actions-6e4628be8b1b) was originally published in [Towards AI](https://pub.towardsai.net) on Medium, where people are continuing the conversation by highlighting and responding to this story.