Skills on Marian Zeis Blog

Testing Joule Work Desktop with Microsoft 365, Local Files, and SAP

Wed, 12 Aug 2026 03:00:00 +0200

You have probably seen Joule Work Desktop on LinkedIn by now. Sebastian Steinhaeuser showed how it prepares him for a customer meeting. Philipp Herzig called it the new SAP GUI, with a smile, and demonstrated a workflow across email, a spreadsheet, a Space, and PowerPoint.

Joule Work Desktop is now available to SAP employees after a test with more than 6,000 colleagues. Selected customers can also use it through the Early Adopter Care program on macOS and Windows.

The idea is simple: one desktop application that can combine local files, Microsoft 365, SAP knowledge, business systems, MCP connectors, and skills. That is much more interesting than another small Joule chat window inside one SAP application.

I already built similar setups with LibreChat and Microsoft Copilot Studio. A native application adds direct access to the files and applications people use every day.

Luckily, I was one of the few people who got access to the application and could test the currently available features. So here is my first hands-on experience with what I am allowed to show.

If you prefer to see the complete flow first, here is the 58-second demo video.

The application starts with Conversations. I can add files and select work sources or an external connector from the composer. Tool calls remain visible, and generated files open in their normal desktop application.

Email and calendar integration

I asked the application to prepare me for a meeting. It found the calendar entry, read related email messages, and created a brief with logistics, open points, risks, and questions. The calendar and email steps remained visible, and the answer included source references. For me, this is more useful than a general inbox summary because the message becomes the start of a task.

Local files, OneDrive, and real documents

I can attach Office documents, structured data, text, and images. Files synchronized through OneDrive are also available, so they can be combined with email, calendar, web research, or an external connector.

For the meeting-preparation example, I attached an existing Word template. The application filled the relevant sections and created a new document instead of giving me text to copy manually.

The files still need review, but reviewing a prepared document is often faster than starting with an empty one.

Spaces are more useful than I expected

SAP calls the generated work areas Spaces. They are persistent views that can be reopened without finding the original conversation. The most useful one in my test was a transport backlog based on data from my SAP system. It shows open and empty transports, their owners, and the biggest requests by object count.

This does not replace a proper application or reporting solution. But not every temporary question needs a new Fiori application, and a Space is more useful than a long chat answer.

Connecting the SAP system

The SAP system integration is what can make Joule Work Desktop more than a general desktop agent.

At the moment, the direct SAP business system integration available to me is for SAP S/4HANA Cloud Public Edition. I do not have such a system. My test system is SAP S/4HANA 2023 on-premise.

I therefore added ARC-1, my open-source ADT MCP server. ARC-1 can run locally or as a remote MCP server with OAuth, for example on SAP BTP Cloud Foundry.

I could then read transports, inspect ABAP objects, analyze custom code, check ATC findings, or compare a specification with what actually exists in the system.

The connector still needs valid authentication, and SAP user authorizations still apply. I would start with a development system and read-only access.

Connectors and one-click skills

Joule Work Desktop supports MCP connectors and skills, so SAP does not have to build every integration and workflow itself. The SAP AI Skills Library contains reusable skills that can be imported into Joule Work Desktop with one click.

The skill page shows the repository, license, trust level, and checks before installation. The SAP Fiori Guidelines skill, for example, can be added through the Add to Joule Work Desktop button.

MCP servers provide tools, while skills describe how the agent should use them and what it should verify. This keeps the application extendable without adding every possible SAP feature to the desktop client.

The open questions are broader SAP system support, connector governance, and pricing. Anything about future announcements or TechEd is still only speculation.

Something is strange

Anyone who already works with Joule Work Desktop may have noticed something by now.

Some details in my video and screenshots do not look exactly like the application SAP installed. The interface is very close, the workflows work, and the features are there, but a few things are just slightly different.

There is a simple reason for that.

I do not have access to Joule Work Desktop.

The screenshots and video in this post do not show an SAP application. They show an application I built myself.

After watching the public demos, I wanted to see how difficult it would be to rebuild the same core idea with open-source components. I spent roughly a day or two vibe coding it with Codex. The result is called Werkbank.

Werkbank is the German word for workbench, a place where different tools come together to get work done.

The current interface follows the public Joule Work Desktop videos closely because I wanted to reproduce the workflows shown there. But there is no internal SAP code behind it, I had no access to a Joule Work Desktop build, and I have no additional product information beyond public posts and videos.

What is actually inside Werkbank

Werkbank is a working MVP, not a static mock or a prerecorded animation. It can hold real streaming conversations, call tools, ask for permissions, and stop a running task. The agent behind it is goose, an open-source AI agent hosted by the Agentic AI Foundation. Werkbank communicates with Goose through the Agent Client Protocol.

The implemented features currently include:

Local active and archived conversations.
Word, PowerPoint, text, CSV, JSON, and image attachments, including files synchronized through OneDrive.
Generated Word and PowerPoint files that can be opened in the normal desktop application.
Persistent Spaces stored as sandboxed HTML views.
Live read-only Microsoft 365 email and calendar access.
Session-scoped MCP connectors, remote MCP OAuth through Goose, and reusable skills selected with /.

The demo uses these features rather than special video fixtures. The meeting brief comes from live calendar and email calls, the Word output is a real file, ARC-1 reads my SAP system, and the transport Space is generated from those results. The shipment-defect workflow uses an attached synthetic CSV file and creates a real Space and PowerPoint presentation.

For SAP, Werkbank uses the same MCP servers I can use from Claude Desktop, Codex, VS Code, LibreChat, or Copilot Studio. ARC-1 connects to the ABAP system. Connector secrets are stored through the operating system’s secure storage instead of being written into the normal configuration.

The project website is getwerkbank.com, and the source is in the public Werkbank repository. Development currently targets macOS, and there is no signed installer yet.

The Werkbank App Store

getwerkbank.com is not only a landing page. Its App Store already works with the desktop application, and I can use it to add both MCP servers and skills to Werkbank.

The small curated catalog currently contains nine entries: three MCP servers and six SAP development skills. I can search it, filter by type, inspect the original source, and then click Add to Werkbank or Add skill.

The website validates the request and opens the local application through a werkbank:// link. Werkbank then shows the connector command and configuration fields, or the skill repository and name. Nothing is installed until I confirm it inside the desktop application. After that, a connector is restarted and becomes available to the conversation, while an installed skill appears in the / picker.

The same flow can be linked from any project README with an Add to Werkbank button. Here is the skill used in the video:

Add the SAP Fiori Guidelines skill to Werkbank

To try it, clone the repository, run npm install, copy .env.example to .env, add the model configuration, and start it with npm run dev.

What this little experiment shows

Werkbank is not a replacement for Joule Work Desktop. It is a small MVP built in roughly two days, with bugs and much narrower workflows. But it is already a usable desktop application: I can chat with it, attach files, connect tools, install skills, and return to earlier conversations and Spaces.

SAP also has to solve the difficult enterprise parts: identity, authorizations, data protection, auditing, deployment, updates, model governance, and reliable operation for many users and systems. A local MVP does not solve these problems just because the demo looks similar. With more time, I could add SSO, authentication against IAS, a release pipeline with signed builds, automatic updates, and more enterprise controls. That was not the main point of this experiment.

But the experiment still shows something useful. The core workflows SAP currently demonstrates are already possible with open-source components:

Read email and calendar context.
Work with local files and OneDrive-synchronized files.
Analyze structured data.
Create persistent dashboards.
Generate real Word and PowerPoint files.
Connect SAP documentation and SAP systems through MCP.
Add reusable skills and new connectors.

Goose is only one possible base. LibreChat can provide a similar experience in the browser. Microsoft Copilot Studio can combine Microsoft 365 connectors and MCP servers. Claude Desktop can also work with local files, connectors, and skills. The individual building blocks already exist.

The real value of Joule Work Desktop will therefore not come only from having these features. It will come from how well SAP connects them to business context, SAP authorizations, supported applications, and real processes. It will also depend on how accessible it is. Are Signavio, LeanIX, or SAP S/4HANA Cloud Public Edition required? Can a customer use it with only on-premise systems? And what will it cost?

For now, I am impressed by the direction. I just could not test the real application yet, so I built the part I wanted to test myself.

Disclosure: Werkbank is an independent open-source project and is not affiliated with or endorsed by SAP. SAP, Joule, ABAP, SAP Fiori, SAP S/4HANA, and other SAP products and services mentioned herein are trademarks or registered trademarks of SAP SE or its affiliates in Germany and other countries.

References and links

ARC-1 1.0: One Deployment, Multiple SAP Systems

Mon, 03 Aug 2026 07:00:00 +0200

ARC-1 1.0 is here.

When I published the first ARC-1 post, I explained why I built an MCP server for ABAP development and why security has to be part of it from the beginning. This post is not another deep dive into every tool. The release notes already do that.

For version 1.0 I want to focus on what really changed: ARC-1 became more stable, it can serve multiple SAP systems from one BTP deployment, the BTP and security setup is much better documented, and the project is no longer only one repository.

Most of this happened because people used ARC-1, asked difficult questions, reported problems, opened issues and pull requests, sent me private messages, and invited me to Teams meetings about their plans and experiences. That is the most important part of this release.

What version 1.0 means

Version 1.0 does not mean ARC-1 is finished. It means there is now a stable base.

ARC-1 now has a clearer scope. It is a controlled connection between AI assistants and ABAP systems. It can run locally for one developer or centrally on SAP BTP for a team. It supports classic on-premise ABAP, S/4HANA, BTP ABAP Environment, and S/4HANA Cloud Public Edition.

It stays read-only by default. Changing code, reading business data, running SQL, changing transports, or using Git has to be enabled separately. This makes it possible to start small and only allow more when a team is ready.

The new multi-system mode is still marked as experimental because parts of the setup and behavior may change. But it can already be used and is running in productive BTP environments, not only in my own setup.

That is what 1.0 means to me: not that every possible ADT feature exists, but that the foundation, operating model, and safety boundaries are clear enough to build on.

This release was built through feedback

The first versions were mostly based on my own systems and workflows. That changed quickly. SAP systems, releases, login setups, networks, and transport processes are too different to understand from one landscape.

Public issues and pull requests brought real system shapes into the project. A few examples:

Wouter Lemaire added the first BTP Cloud Foundry deployment, followed it with deployment and write fixes, and continued to give very practical guidance on BTP, destinations, and how a shared ARC-1 service should be operated.
Sami Bouguerra contributed NetWeaver 7.50 probe fixtures and cookie handling, then fixed cases where activation looked successful although SAP had not activated the object in PR #179.
Clément Ringot made BTP login more reliable across deployments in PR #212 and PR #267, and fixed Cloud Connector response handling in PR #440.
Geert-Jan Klaps added S/4HANA Public Cloud support. I do not have access to such a system myself, so his contribution made it possible to add and verify this landscape in ARC-1.
Community pull requests added table queries, newer package creation, safer transport handling, better BTP login, configurable server names, and cookie rotation. You can find them in the repository’s pull requests.

Not every useful contribution was code. Issues such as multi-system connections and how to structure several systems on BTP changed the architecture and documentation. Reports from older systems improved release detection and fallbacks. Questions from Basis and security people forced me to make assumptions explicit instead of hiding them in configuration examples.

I also received many private messages and joined Teams meetings about ARC-1. Some people explained how their teams want to deploy it on BTP and walked me through their real landscape and requirements. Others pointed out security issues, unclear documentation, or places where the safety boundaries were not strong enough. These conversations directly improved login, error handling, audit information, package restrictions, user identity, and the deployment guides.

Thank you especially to everyone who reported a security concern privately. That is exactly how an open-source security process should work. ARC-1 now has a public security policy, private vulnerability reporting, automated checks for code and dependencies, container checks, and an inventory of the software included in each release.

One ARC-1 instance, multiple SAP systems

The biggest addition in version 1.0 is the experimental multi-system mode.

You can now deploy one ARC-1 application on SAP BTP Cloud Foundry and attach several SAP systems or clients through destinations in the same subaccount. An administrator chooses which destinations belong to ARC-1. It does not connect to every destination by accident.

This is already used in productive BTP environments. Experimental in this case means that configuration and behavior can still change as more landscapes use it. It does not mean that the feature is only a local proof of concept or that people cannot use it today.

Each system and client gets its own MCP address. There is also an optional combined connection for tasks that really need several systems. A system-specific address is the safer choice for normal work because the conversation is already connected to the correct target.

Keeping the real user identity is the recommended setup. A user logs in on BTP and the identity is forwarded to SAP. SAP then checks the same authorizations the person already has. A shared technical user is possible for special cases, but it gives less clear responsibility and needs more care.

This feature started with community requests and Wouter’s first multi-backend implementation. His code and BTP experience gave the final design important groundwork. The production-focused design, security review, tests, and administrator documentation then landed in PR #579.

The biggest changes in short

I do not want to explain every feature here. These are the areas that matter most for 1.0:

Safer operation: ARC-1 starts read-only. Higher-risk actions are separate choices, SAP still decides what the user may do, and teams get limits and audit information for shared use.
More SAP compatibility: testing and fixes now cover older NetWeaver systems, several S/4HANA releases, ABAP Platform 2025, BTP ABAP Environment, and S/4HANA Cloud Public Edition.
Better BTP guidance: the BTP overview, Cloud Foundry guide, user identity guide, updates, rollback, destinations, roles, and multi-system operation are now documented as one path.
Reusable workflows: 22 included skills cover RAP, tests, migrations, Clean Core analysis, transport reviews, system documentation, and more.
More checks before a release: ARC-1 runs automated tests against the code and real SAP systems, checks dependencies and containers, and publishes information about what is included in a release.

For the exact technical list, including fixes for transport state, ABAP object types, BTP token exchange, tracing, and protocol compatibility, use the release notes and the GitHub v1.0.0 release.

Skills for complete SAP tasks

ARC-1 1.0 includes 22 skills. A skill is a reusable workflow for an AI assistant. It gives the assistant a tested way to approach a larger task instead of relying on one large prompt.

The included skills cover creating RAP services and logic, ABAP and CDS tests, analytical models and queries, explaining and documenting existing code, finding slow SQL, Clean Core and S/4HANA migration work, unused-code checks, transport overviews and reviews, and modernizing legacy UI5 applications. There are also helpers to understand a system first, create a local ABAP mirror, and review an AI session. The full skills catalog has the complete list and installation options for Claude Code, GitHub Copilot, Cursor, Codex, and other assistants.

The SEGW-to-RAP skill deserves a special mention. It reads an existing SEGW OData V2 service, including its model and custom code, and guides the move to a modern RAP V4 service. My SEGW-to-RAP post got one of the biggest responses of the whole ARC-1 series. That was a clear signal that many teams are not only interested in creating something new. They also need practical help to modernize the large amount of existing SAP applications.

Extensions for your own SAP APIs

ARC-1 will never include every custom API or company-specific endpoint. Forking the complete server for one internal tool is also difficult to maintain.

The extension framework gives you another option. It lets you add your own tools and reuse the SAP connection, safety checks, and audit path of the ARC-1 instance. This can be useful for an internal service or any API that is not part of the standard ARC-1 tools.

The extension sample shows a simple configuration option and a code option. It also shows the safety limits. An extension cannot give itself more access than the ARC-1 instance already has, and changes still need to be enabled explicitly. Code extensions run inside ARC-1, so they should be reviewed like any other dependency.

LISA is already a useful real example. It provides SAP translation tools as a standalone MCP server and as an ARC-1 extension. This proves both paths can work: build a separate focused service, or attach the capability to an existing ARC-1 deployment.

Reusing the BTP authentication stack

Login and keeping the correct SAP user were some of the hardest parts of ARC-1. Other SAP MCP servers need the same foundations, so this code is now available as the separate @arc-mcp/xsuaa-auth package.

It provides the core pieces for deploying an MCP server to SAP BTP Cloud Foundry: login through XSUAA, reuse of BTP destinations, connections through Cloud Connector, and forwarding the real user to SAP. A project can reuse this setup and keep its own focused SAP API instead of copying the full ARC-1 server.

ARC-1 uses the package itself. LISA and ROSA use it as well, and BW Modeling MCP now uses it for its central SAP BTP Cloud Foundry setup. For me this is an important part of the release. The value of ARC-1 is not only the number of ABAP tools. The deployment and security principles can now help other projects too.

A new home for the project

ARC-1 moved from my personal GitHub account to the arc-mcp organization. There is also a dedicated landing page, full documentation at docs.arc-1-mcp.com, and a live replay demo that works without a SAP system, credentials, or a live LLM.

The organization now contains the main product, reusable components, experiments, and demos that are still active:

arc-1: the main SAP ADT MCP server.
xsuaa-auth: reusable XSUAA, OAuth, and BTP Principal Propagation.
arc-1-extension-sample: examples for custom ARC-1 tools.
adt-ls: a TypeScript SDK for SAP’s headless ADT language server.
arc-1-lsp: an experimental MCP server built on that language-server path.
arc1-adt-abap-mcp-ext: an Eclipse extension adding read-only tools to SAP’s ADT MCP server.
arc-1-abap-cicd-review: an ABAP review workflow with GitHub Actions, abaplint, AI review, and live SAP checks.
arc1-transport-review-poc: a proof of concept for reviewing SAP transports through pull requests.
arc-1-segw-to-rap: the SEGW, RAP, UI5, and Fiori elements modernization demo.
arc-1-mcp.com: the source of the landing page.
live-arc-1: the source of the interactive replay demo.

Not every repository has the same maturity. ARC-1 is the stable core. Some projects are reusable packages, some are beta, and some are intentionally proofs of concept. Keeping them separate makes this more visible and lets each idea develop without making the main server bigger.

Where to start

If you are new to ARC-1, use the quickstart with a development or sandbox system and start read-only. The live demo is useful if you first want to see how the workflows and tool calls look.

For a team deployment, start with the BTP overview. Decide the topology, identity model, destinations, and responsibilities before enabling more capabilities. Principal Propagation should be the normal choice when SAP needs to see the human user.

If you already run ARC-1, follow the update guide and review the release notes. For production, pin a version instead of using latest, keep the first acceptance test read-only, and review the current SAP API policy and your own agreements before enabling data preview or free SQL.

ARC-1, SAP’s MCP server, and the API policy

SAP now also provides its own ABAP MCP server as part of the ABAP Development Tools. I do not see this as an either-or decision.

SAP’s server is the natural choice for a developer who works inside VS Code or Eclipse and wants to reuse the existing IDE connection. ARC-1 has a different focus. It can run as a shared service on BTP, serve different AI clients and team workflows, cover classic and modern ABAP use cases, and give administrators one place for access rules and audit information. Many teams can use both.

The detailed ARC-1 and SAP ABAP MCP Server comparison explains where each option fits, where each one is stronger, and where each one has limits. It is meant as a decision guide, not as a sales comparison.

More important for a wider rollout is the SAP API Policy and architecture guide.

ARC-1 uses the ADT interfaces behind SAP’s ABAP development tools. These interfaces have been used by SAP and third-party developer tools for many years, but the ADT web endpoints are not listed as published APIs in the SAP Business Accelerator Hub. SAP’s current API policy also talks directly about access by generative AI and autonomous agents.

At the same time, SAP has published an architecture for third-party MCP servers. ARC-1 is close to this architecture, especially when it runs on SAP BTP Cloud Foundry with BTP login, destinations, Cloud Connector, the real SAP user identity, traffic limits, and audit logging. This is a good technical fit, but it is not by itself a legal approval for every customer and every landscape.

My recommendation is simple. Start in development or test, start read-only, and keep SAP authorizations in control. Before a broader or production rollout, ask your SAP contact whether your agreement allows third-party tools to use the ADT endpoints in this way. The policy and SAP guidance can change, so check the current documents instead of relying only on this post.

Thank you

ARC-1 1.0 is not the result of one large feature. It is the result of many small reports, tests, discussions, fixes, and reviews.

Thank you to everyone who opened an issue or pull request, tested another SAP release, shared a BTP setup, challenged a security decision, built an extension, tried the documentation, or sent a private message. Even when I could not implement an idea directly, the feedback helped make the project clearer and safer.

Feedback is still greatly appreciated. Open an issue when something does not work or the documentation is unclear. Send a pull request when you have a fix or improvement. A private message is also welcome, especially when you want to share details about a real landscape or raise a security concern.

Version 1.0 is a milestone, not the end. Now there is a stable base, public documentation, a clearer security process, and a growing set of reusable projects around it.

Creating an ARC-1 BTP Diagram with Codex and a draw.io Skill

Thu, 09 Jul 2026 09:00:00 +0200

I wanted one practical thing: an editable draw.io diagram for ARC-1 on SAP BTP that looks like it belongs in the SAP Architecture Center.

My first attempts with generic diagram prompts were not really useful. They often had dark backgrounds, icons that were too large, and arrows running through boxes. I wanted something closer to the SAP examples: a white canvas, the right BTP areas and service icons, understandable flows, and an editable draw.io file that I could still correct by hand.

That became marianfoo/btp-drawio-skill, a skill for creating SAP Architecture Center-style .drawio files from plain text.

Where this started

I did not start this from zero. The main source was SAP itself, and there are two related projects that are easy to mix up:

The SAP BTP Solution Diagram Guidelines define how these diagrams should look: levels, areas, colors, icons, connectors, labels, and legends. The complete guideline and editable examples are in SAP/btp-solution-diagrams.
The SAP Architecture Center publishes real reference architectures for topics such as integration, identity, data, AI, and resiliency. Their source, including many editable .drawio files, is in SAP/architecture-center.

The skill bundles selected diagrams and assets from these official sources. This gives the model both parts it needs: the visual rules and real SAP-authored examples.

Two community projects also appeared almost at the same time.

Wouter Lemaire published lemaiwo/btp-drawio-skill on April 17. I took inspiration from its Claude marketplace structure and the idea of bundling the SAP icon XML libraries directly with the skill.

One day later, miyasuta/claude-drawio-btp-diagram appeared. I liked its separation between official guidelines, conventions, and concrete draw.io styles. Its center-alignment rule for straight connectors also became an important detail in my implementation.

I started my repository on April 22 because I needed the ARC-1 diagram. From there I added a larger SAP Architecture Center corpus, template ranking, asset extraction, built-in fallback layouts, validation, scoring, visual comparison, and the nudge loop.

The main lesson stayed simple: do not generate SAP diagrams from scratch when SAP already published the visual language and many real examples.

Before the example, it helps to understand what the skill actually does.

How the skill works

Without the skill, the model starts with an empty canvas and has to invent the layout. With the skill, it first decides what kind of diagram is needed and then looks for the closest SAP example.

SAP defines three diagram levels based on the audience and required detail:

L0 is a business overview. It uses only a few blocks and simple neutral arrows. Technical details are left out.
L1 is a conceptual architecture. It shows named SAP services, the main zones such as BTP and on-premise, and the important flows between them.
L2 is a logical or technical architecture. It adds protocols, identity and trust flows, connector labels, and a legend. The ARC-1 example in this post is an L2 diagram.

The complete workflow looks like this:

Your architecture description
            |
            v
Choose the level and closest SAP example
            |
            v
Copy and adapt the example
            |
            v
Validate -> render -> inspect -> correct
            |
            v
Editable .drawio file and PNG

The repository currently bundles 71 reference templates, 100 SAP BTP service icons, and 448 indexed draw.io assets. Most templates come from the two official SAP repositories above, with a few additional public SAP examples.

Find a starting point. scaffold_diagram.py ranks the templates and copies the closest one. This copy is the scaffold.
Adapt only what changed. The model keeps the SAP layout and uses helpers such as relabel.py, extract_icon.py, and extract_asset.py to change labels and assets.
Use a smaller fallback when needed. If the closest template is much larger than the requested diagram, render_semantic.py can create a smaller layout for a few known patterns while keeping the SAP visual rules.
Check the result and look at it. autofix.py repairs known mechanical problems. validate.py checks colors, fonts, icons, labels, and arrow routing. score_corpus.py compares the result with the SAP examples. Then iterate.py and render_compare.py render the diagram so the model can inspect and correct it.

The important limit is that these checks only understand the file and its visual structure. They do not know if the architecture itself is correct.

The sample use case in Codex

For the sample, I used the exact problem that started this project: a developer in VS Code asks an AI assistant to inspect an ABAP class through ARC-1.

Developer and AI assistant in VS Code
                |
               MCP
                v
ARC-1 on SAP BTP Cloud Foundry
                |
Destination + Connectivity + Cloud Connector
                v
On-premise SAP ABAP system

XSUAA authenticates the client. Destination Service and Connectivity Service route the request through SAP Cloud Connector. Principal Propagation keeps the developer’s identity for the ABAP call.

The diagram should make this complete path understandable for an SAP platform or development team. I used Codex to create it and kept the first result, the correction, and all validation output for the example below.

The skill started as a Claude Code plugin, but the important part is portable. It is a folder with Markdown instructions, SAP templates, local assets, and Python scripts.

For Codex I cloned the repository and pointed an AGENTS.md file at the skill:

git clone https://github.com/marianfoo/btp-drawio-skill.git

For SAP architecture diagrams, use the sap-architecture skill at
<path>/btp-drawio-skill/plugins/sap-architecture/skills/sap-architecture.

Read SKILL.md completely. Always scaffold before editing. Run autofix,
validate, score, render, and inspect the image before finishing.
Never write the draw.io XML from scratch.

Codex reads the project instructions and can call the scripts directly. Python 3.8 or newer and shell access are required. The draw.io desktop app is only needed for PNG, SVG, or PDF export.

For the example I described one focused L2 architecture:

Create an L2 SAP Architecture Center-style diagram.

A developer uses an MCP-capable AI assistant in VS Code to inspect an ABAP
class through ARC-1. ARC-1 runs on SAP BTP Cloud Foundry and exposes /mcp
over Streamable HTTP. The client authenticates through XSUAA. ARC-1 resolves
a PrincipalPropagation destination, uses Connectivity Service and SAP Cloud
Connector, and reads the on-premise SAP ABAP system through ADT REST.

Zones: Developer Workstation, SAP BTP Cloud Foundry,
Customer On-Premise Network.

Output an editable .drawio, PNG, validation and score results,
and the numbered flow narration.

The complete prompt and a sanitized copy of the AGENTS.md used for the run are attached to this post.

Codex worked for 6 minutes and 42 seconds. It read the skill, ran the template selector, created a first pass, validated and rendered it, inspected the image, made one correction, and ran the checks again.

The selector correctly ranked ac_RA0001_E2B_CloudConnector.drawio first. But this SAP reference has 24 cards and a much larger scope. Removing enough cards for my focused ARC-1 flow would remove more than one third of the template.

Codex therefore switched to the skill’s built-in on-prem-connectivity renderer. This was one of the improvements I added: start with the closest SAP example, but do not force a large template into a much smaller use case. The renderer still uses the same SAP palette, dimensions, assets, and validation rules.

The first pass scored 100, but was wrong

This was the first complete diagram:

The validator returned OK, and the reference-free SAP-likeness score was 100.0/100.

That sounds good, but it was still wrong for my use case.

The title was generic. The VS Code flow used HTTPS instead of MCP. The backend connection said OData/REST, although ARC-1 uses the ADT REST API. It also named SAP S/4HANA even though I wanted a generic on-premise SAP ABAP system.

This is the part I find most useful. A score can tell me that the file follows the expected visual rules. It cannot prove that the architecture says the right thing.

Codex inspected the rendered PNG and made one focused correction. It kept the layout and corrected the labels and colors: MCP in teal, XSUAA and Principal Propagation in green, ARC-1 as the purple focus application, and ADT REST for the backend call.

The final result passed validation without errors or warnings. Its SAP-likeness score was 96.7/100, slightly lower than the first pass, but the diagram was now correct for ARC-1. The scorer still reported two vocabulary advisories for OAUTH JWT and mTLS PP. I kept them because they explain the exact identity flow and are already part of the skill’s L2 layout guidance.

While preparing this post, I found one more export problem. The draw.io file did not store the white page background explicitly, and one PNG export came out black. I set the page background to white in both attached .drawio files and exported them again. The validator had accepted the missing value as the default background. This was another useful reminder that I still need to look at the final image.

That is also why I would use a strong reasoning model for this task. The skill removes a lot of guessing, but the model still has to read the workflow, choose between a template and fallback, understand the architecture, inspect an image, and notice when a high-scoring result is semantically wrong. I did not compare several Codex models in this run, so this is not a model benchmark.

The artifacts from the run are available here:

How to prompt it

The skill works best when the prompt describes an architecture, not only a product list. Include:

Level: L0, L1, or L2, based on the audience and required detail.
Audience: business overview, solution architecture, or implementation team.
Zones: client, SAP BTP, SAP cloud applications, on-premise, or third party.
Exact services: this improves SAP icon and asset selection.
Backend systems: for example SAP S/4HANA, ECC, BW/4HANA, or a generic ABAP system.
Identity: IAS, XSUAA, OAuth, SAML, Principal Propagation, trust, and authorization.
Numbered flow steps and protocols such as MCP, HTTPS, ADT REST, OData, A2A, or SAML2/OIDC.
Constraints and exclusions: what must be shown and what should stay out.

A weak prompt is:

Draw ARC-1 with BTP and SAP.

That leaves the model guessing about the level, zones, identity, backend protocol, and even the purpose of the diagram.

The skill is also an authoring assistant, not a one-shot generator. Give visual feedback such as:

“The icons overlap the text. Use the normal SAP icon size.”
“The MCP flow should be teal.”
“Cloud Connector belongs in the on-premise network.”
“The backend call is ADT REST, not OData.”

Specific feedback maps to a concrete edit. “Make it better” usually does not.

Where it works and where it stops

It works best for a focused L1 or L2 diagram with explicit zones and flows, especially when a reference from the same architecture family exists.

Sometimes no close template exists. Then another model retry does not solve the problem. The skill can use a deterministic fallback for a few known patterns, but other diagrams still need manual draw.io work or another reference template.

The validator also cannot prove semantic correctness. The Codex run above showed that clearly. A diagram can be valid, visually SAP-like, and still use the wrong protocol or product name.

For me, the value is not a perfect architecture from one sentence. The value is a much better editable first draft, a repeatable way to check it, and a clear loop for the last correction.