# Golden Passport
> Luke Audie. Fifteen plus years in business automation and process architecture, built at IDS Scheer, Software AG, Red Hat and UiPath. Writing on automation, operations, and the tools that make modern businesses run.
Author: Luke Audie (https://www.linkedin.com/in/lukeaudie)
Site: https://goldenpassport.blog
Generated: 2026-05-27T13:00:11.406Z
This document contains the full text of every published post on Golden Passport, in reverse-chronological order. Frontmatter has been stripped; the rest of each post is included verbatim. Republished posts are marked with their canonical source URL.
---
# Welcome to Golden Passport
URL: https://goldenpassport.blog/blog/welcome-to-golden-passport
Date: 2026-05-26
Category: Business
Tags: Strategy, Brand, Automation
> Why I’m starting a blog about automation, and how the Business and Tech tracks fit together.
This is the first post, so it gets to be a manifesto.
I’m starting Golden Passport because most automation projects fail in the same boring way: not the
tech, but the seam between what the business wants and what the tech can credibly deliver. I sit on
that seam for a living, and I wanted a place to write about it openly.
## Two tracks, same audience
Posts here come in two flavours:
- **Business.** Operating models, where automation pays back, how to scope it without burning the
team out, when *not* to automate.
- **Tech.** Patterns, tools, trade-offs. Working code where it helps the point land.
Same reader, often. Operators who care about how the sausage is made; engineers who care why
they’re making it.
## What you can expect
Short posts when a short post is enough. Longer ones when the topic deserves it. No clickbait, no
trend-chasing. Just the things I actually run into, written down while they’re fresh.
Thanks for being early. More soon.
---
# Building a Design System for Automation UIs
URL: https://goldenpassport.blog/blog/building-a-design-system-for-automation-uis
Date: 2026-05-27
Category: Tech
Tags: Design System, PatternFly, React, BPM, KIE, Accessibility, i18n, Open Source
> Why I built @golden-passport/ds-patternfly: an open-source accelerator for automation and workflow projects, sized to the shape of real business-centric work. Brandable, accessible-by-default, built on PatternFly 6.
If you have ever built a UI for a business-centric automation engine, you know the shape of the friction. The engine itself is rigorous: KIE, jBPM, the rules layer, the workflow layer. The data model is rich. The runtime is battle-tested. And then somebody asks for a screen, and you find yourself rebuilding the same five things you rebuilt on the last project.
The same modeller pane. The same task inbox. The same primary-detail layout with a list on the left and a form on the right. The same brand override of a vendor design system, where you spend a week persuading two colour variables to be different shades of the same blue. The same accessibility checks that get sidelined under deadline pressure. The same English-only buttons that need to ship in five languages by Q3.
I have done this enough times now to know it is not a one-off problem. It is the shape of the work.
That recurring friction is why I started [`@golden-passport/ds-patternfly`](https://github.com/GoldenPassport/ds-patternfly): an open-source accelerator for automation and workflow projects that require human interactions. A small, opinionated React design system built on PatternFly 6, sized specifically to the way business-centric automation UIs actually want to be built. This post is half the *why*, half the *how*. If you build automation interfaces for a living, the patterns here are probably the ones you already wish you had.
## A quick word on PatternFly (and why it matters)
If you have not come across it before: PatternFly is Red Hat's open-source design system for enterprise software. The same way Tailwind is a default reach for utility-first CSS, or shadcn for composable React components, PatternFly is a default reach for the enterprise-application end of the React spectrum. It is what you pick when the people using your UI are doing serious work: configuring workflows, approving compliance flows, monitoring infrastructure.
A few things set it apart in a crowded design-system landscape:
- **Fully open-source, no paywall.** Every component, every variant, every accessibility primitive. There is no "PatternFly Pro" tier you discover halfway through your project. The kitchen sink is in the kitchen, free.
- **A serious enterprise backer who uses it themselves.** Red Hat ships PatternFly inside their own products (OpenShift, Ansible Automation Platform, the KIE workbench, and more). That is a different funding model from a hobby project or a venture-backed startup looking for a monetisation moment: PatternFly has a multi-year roadmap because Red Hat needs it to.
- **A mature ecosystem.** Years of accessibility work, a documented design language, hundreds of stories, public Figma assets, and a working community. You start from a place where the hard problems are already solved.
- **Visual continuity by default.** If your automation UI sits next to a KIE workbench, an OpenShift console, or any other Red Hat surface in the same workflow, your users see a coherent design language across all of them. They do not have to learn three different button styles to do their job.
That last point is worth lingering on for an automation audience. The React design-system conversation in 2026 is loud. shadcn, Radix, Mantine, MUI, Chakra, the next thing. Lots of strong options. PatternFly is the quiet, less-fashionable answer that happens to fit this domain perfectly, because the rest of the platform is already speaking the same language.
There is a price, and it is honest to name it. PatternFly is opinionated about its visual identity, so out of the box your product looks like Red Hat's product. Branding it well, without breaking accessibility or quietly reinventing buttons in three places, takes more discipline than most product teams have time for.
So I leaned in. `ds-patternfly` is PatternFly 6 underneath. It does not try to replace it, and it does not try to extend it sideways. What it adds is three patterns that PatternFly itself, deliberately, leaves open.
## Pattern 1: Branding as a typed token contract
The first job is making PatternFly look like *your* product, not Red Hat's. PatternFly already exposes its design tokens as CSS custom properties. The hard part is doing the override safely, in a way a designer can hand a developer without anyone having to grep through Sass files.
In `ds-patternfly`, a brand is a TypeScript object that overrides specific PatternFly variables. You import it once at the root of the app, and the whole tree picks it up.
```tsx
import "@patternfly/react-core/dist/styles/base.css";
import "@golden-passport/ds-patternfly/styles";
import {
ThemeProvider,
AppShell,
goldenPassport,
appShellEnLabels,
} from "@golden-passport/ds-patternfly";
export default function App() {
return (
}>
{/* your screens */}
);
}
```
Want a different brand? Define another `BrandTokens` object, pass it to the same `ThemeProvider`, ship. The components do not change. There is no parallel theming system fighting PatternFly's CSS variables. The override is the variables.
A few things this buys you:
- **Designers stay in design-token land.** The brand object is a flat, typed list of colour, spacing, and radius values. It is what a designer expects to hand over: a set of values, not a Sass partial.
- **Multi-brand is a `prop` change.** If you build automation UIs for multiple clients or multiple internal product lines, swapping brands at the root is a one-line change.
- **Contrast is enforced.** Brand colour contrast is validated by tests (more on this in a moment). You cannot ship a brand that quietly fails WCAG without the test suite telling you.
- **No Tailwind.** Deliberate. PatternFly already has its own design language and its own CSS scope. Layering Tailwind on top creates two competing systems and twice as much footgun.
## Pattern 2: Accessibility as a CI gate, not an afterthought
Enterprise software is used by all kinds of people, with all kinds of abilities. Operations teams. Compliance officers. Auditors. Field workers using a tablet in poor light. People who navigate exclusively by keyboard. People who rely on screen readers. The applications that run a regulated business are not a niche audience that anyone can opt out of supporting, and accessibility is not an afterthought.
Every team I have worked with intends to be accessible. Most teams I have worked with do not have automated infrastructure that proves it. Accessibility ends up being a thing somebody does manually before launch, and then somebody else regresses three weeks later when a new variant of a button ships.
`ds-patternfly` treats accessibility the same way most teams treat type-checking: it is a CI gate, and the build fails if you break it.
The way this works is worth a closer look, because it is the kind of setup most projects could adopt today without rewriting anything.
- Every component has at least one **Storybook story** covering its primary states.
- Storybook is wired to **Vitest** via `@storybook/addon-vitest`, which renders every story in headless Chromium during the test run.
- Each rendered story is scanned by **axe-core**, via `@storybook/addon-a11y`'s Vitest integration.
- Any WCAG 2.0 / 2.1 / 2.2 AA violation fails the run. The same results show up live in the Storybook UI's Tests pane during local development.
The CI-facing entry point is one command:
```sh
pnpm test:storybook
```
This runs `vitest run --project=storybook`, which is the axe-only subset. The full `pnpm test` adds Node-mode unit tests. First-time setup needs Playwright's Chromium, which Storybook orchestrates under the hood:
```sh
npx playwright install chromium
```
The shift this represents is small in code and large in posture. Accessibility is no longer "we should test that." It is "the build is red, somebody go look." Every PR that adds a new component or a new state of an existing component automatically scans it. New developers cannot ship code that fails AA without the system flagging it. Designers can also see the same results in Storybook locally, which makes the conversation about a contrast fail or a missing label something both sides of the desk can act on.
WCAG 2.2 AA is the target. Beyond catching obvious mistakes (missing labels, contrast failures, focus traps), it pushes the library design toward components that *cannot* be misused in inaccessible ways. Required ARIA props become required TypeScript props. The compiler enforces what axe would catch.
## Pattern 3: i18n by props, not by bundling
The third pattern is the one that surprises people. Most React design systems ship with built-in localisation: a runtime, a locale switcher, sometimes a JSON file per language baked into the bundle. The intent is good. The consequence is that every consuming app inherits that translation pipeline whether they want it or not. That works fine for the rare case where the library author is also the translation owner. It works badly for everyone else.
`ds-patternfly` does the opposite. Every user-facing string in the library is a prop. The library ships with English defaults as opt-in objects, and you pass them in:
```tsx
import { PrimaryDetailLayout, primaryDetailLayoutEnLabels } from "@golden-passport/ds-patternfly";
i.name}
renderDetail={(i) =>
{i.description}
}
labels={primaryDetailLayoutEnLabels}
/>
```
If you have an existing i18n setup, you wire your translated strings into the same shape and pass them in. The library does not ship any localisation runtime. It does not assume your translation tool. It does not bundle locales you do not want. It does not need to know whether you are using `react-intl`, `i18next`, lingui, or a single TypeScript object you maintain by hand.
For automation teams shipping to clients in regulated industries, this is the right shape. Translation is owned by the product team, the SDK gets out of the way, and the type system makes sure you do not forget to translate something. If a label prop is required, the compiler will tell you when a new release adds one.
## What this is not
I want to be honest about scope, because design systems are easy to overpromise.
This is not a replacement for PatternFly. PatternFly is the primitives library. `ds-patternfly` is the opinionated layer on top, specifically shaped for the automation-UI domain. Anything PatternFly offers, you can still use directly.
It is not a kitchen-sink component set. It contains the patterns I keep rebuilding: an app shell with brand slots, a primary-detail layout, the theme provider, the brand token contract, and the testing scaffolding. Not every component you could imagine.
It is not a CSS framework. There is no utility class system. There is no atomic styling. Component styling lives inside the components, against PatternFly's variables.
It is also not a finished product. The repo is a v0 line of work in the open. The interfaces will move. Storybook is the primary surface and is the right place to evaluate it.
## Where it goes from here
The roadmap, in rough priority order:
- **More layout components.** A wizard, a task inbox, a process-instance detail view. The handful of patterns that come up on every automation UI engagement.
- **A brand kit cookbook.** Three to five worked-example brands so a team can see what discipline looks like in practice, not just what the contract allows.
- **Documentation site.** Storybook is the dev surface. A static docs site, generated from the same stories, is the next obvious thing.
- **Token validation.** Static checks that a brand satisfies the contrast contract before it reaches the runtime, so the failure is at build time, not at axe time.
If you build automation UIs and any of this sounds like the conversation you are also having with yourself, I would genuinely like to hear from you. Use the issues tab on the [repo](https://github.com/GoldenPassport/ds-patternfly), or [drop me a message](/contact).
The friction with automation UIs is real, the patterns above keep recurring, and the more of us comparing notes in the open, the faster we converge on the parts of the work that should not have to be rebuilt every time.
---
# Customer Experience Isn’t a Technology Problem
URL: https://goldenpassport.blog/blog/customer-experience-isnt-a-technology-problem
Date: 2026-05-05
Category: Shorts
Tags: Customer Experience, Personalisation, Operating Model, Org Design, BPM, Agentic AI
Originally published at: https://www.linkedin.com/posts/lukeaudie_hyperpersonalisation-customerexperience-bpm-share-7450842341457719296-YgtY/
> The road to true 1:1 customer experience is not about better tools, more data, or smarter AI. It’s about aligning three worlds (technology, business, and design) and the only place to start is with management incentives.
Customer Experience isn’t a technology problem. It’s all about alignment.
Tying together a few of my recent posts, I believe the road to true 1:1 customer experience is not about better tools, more data, or even smarter AI.
It’s about bringing together three fundamentally different worlds inside an organisation:
- **Technology teams.** Focused on integration, platforms, and technical workflows.
- **Business teams.** Focused on end-to-end processes, risk, and compliance.
- **Design teams.** Focused on human interaction, journeys, and experience.
Each comes with its own mindset, incentives, and ways of working. Add in individual measures of success, and teams often end up unintentionally pulling in different directions.
I’ve had the opportunity to work across all three. The more I reflect on it, the more I believe this:
> You don’t start with AI, or even tech in general.
> You don’t even start with business process.
> You start with management incentives.
Curious to hear where others have seen this work, or fail. [Drop me a message.](/contact)
---
# Agentic AI and the Return of 1:1 Personalisation
URL: https://goldenpassport.blog/blog/agentic-ai-return-of-personalisation
Date: 2026-04-27
Category: Shorts
Tags: Agentic AI, Responsible AI, Process Automation, Personalisation, Customer Experience, GDPR
Originally published at: https://www.linkedin.com/posts/lukeaudie_agenticai-responsibleai-processautomation-share-7445256259433287680-g8zd/
> From the butcher who knew everyone’s order, to GDPR pushing back on cookie-led ads. Adaptive processes with agentic AI may finally let us deliver 1:1 personalisation safely, at scale.
Fifty years ago, every high street vendor, whether the butcher, baker, or corner shop owner, knew exactly how each customer liked their order. It was effortless 1:1 personalisation.
The challenge has always been how to bring that same experience online and deliver it at scale. The first major attempt relied on cookies to follow people’s online behaviour and use that data to serve personalised ads and recommendations. GDPR rightly pushed back on that approach.
But the need for personalisation has not gone away. What I am seeing now is a shift towards adaptive processes. Not uncontrolled AI creating one-off experiences with no consistency, but workflows with guardrails, where agentic AI can adjust the journey at the right moments to create better outcomes for customers. Sometimes, moving just a few things around at a key point makes all the difference.
Reach out if you would like to discuss how to balance agentic AI with repeatable, safe processes. [Drop me a message.](/contact)
---
# EU Trade Agreements Are Driving Hyper-Personalisation
URL: https://goldenpassport.blog/blog/eu-trade-agreements-driving-hyper-personalisation
Date: 2026-02-27
Category: Shorts
Tags: Hyper-Personalisation, Customer Experience, Trade, Process Architecture, Data Architecture
Originally published at: https://www.linkedin.com/posts/lukeaudie_mercosur-euindiafta-hyperpersonalisation-share-7432048894399848448-WhAL/
> Record EU trade deals in 2026 (Mercosur, the India FTA) are intensifying competition. Businesses are responding by accelerating hyper-personalisation, starting with data and process architectures.
The EU is signing record trade agreements in 2026, including Mercosur and the FTA with India. This is driving healthy competition across industries such as agriculture, pharmaceuticals, and manufacturing.
In response, businesses are accelerating hyper-personalisation strategies, with an immediate focus on strengthening their data and process architectures.
---
# How to Safely Create Meaningful AI Automation in Regulated Industries
URL: https://goldenpassport.blog/blog/safely-creating-ai-automation-in-regulated-industries
Date: 2025-11-10
Category: Tech
Tags: Agentic AI, BOAT, BPM, RPA, Regulated Industries, Responsible AI
Originally published at: https://www.linkedin.com/pulse/how-safely-create-meaningful-ai-automation-regulated-industries-luke-ja5of/
> A practical method for adopting Agentic AI in regulated industries: Dynamic Paths, deterministic outcomes, and governance that scales.
## TL;DR
If you work in government, finance, healthcare, or another regulated industry, and want a trusted, realistic approach to adopting Agentic AI, this article is for you.
You already know your processes are rigid and rule-bound. You also know they need to become more adaptive. The challenge is that you still require deterministic, auditable outcomes, and it’s not obvious how to reconcile those two worlds.
AI is powerful, but in regulated sectors it’s risky when applied without structure. In this piece, I share a practical method I use called **Dynamic Paths**: an approach for adaptive automation with controlled outcomes, combining governance and agility in a way that works for real organisations.
## Pain and Challenge
In regulated industries, static processes exist for good reasons: years of institutional learning, embedded accountability, and tight oversight. Yet those same ways of working can age badly, creating the perception that your organisation is inflexible and out of touch.
At the other extreme sits unconstrained, AI-led automation. Fast, reactive, and often opaque. It may initially look like innovation, but without guardrails it can quickly lead to gaps in accountability and even recklessness.
Imagine doctors taking an AI-style approach, focusing on next-best-actions without considering upstream history or downstream impacts, producing outcomes that could easily outweigh the intended benefits. Contrast that with the medical industry’s tried-and-tested approach to diagnosis and treatment planning: a measured grouping of steps (not random actions), centred on quality-of-life outcomes that are measurable, evidence-based, and deliberately cautious.
There’s a reason certain things require a "measure first, cut once" philosophy. Healthcare learned that long ago, and regulated AI needs to do the same.
We all want adaptive organisations, but we still demand prescriptive outcomes. That’s the balance we must design for.
The Struggle is Real
## The Opportunity, and Why Context Matters
We know the traditional benefits of automation: standardisation, consistency, reliable service excellence, and the removal of repetitive manual effort that allows teams to focus on higher-value work.
Through AI-led automation, those benefits can now extend even further. Services can adapt to client needs in real time, rather than customers being told, "that’s just how we’ve always done it." This shift ushers in the era of hyper-personalised service at scale, where technology moulds itself to the individual, not the other way around.
But context still matters. AI can hallucinate, misinterpret, or act on incomplete data. In regulated industries, those mistakes have real consequences, from compliance breaches to reputational risk, and in healthcare, even death.
The opportunity is huge, but only if we build automation that’s both adaptive and accountable: flexible enough to respond intelligently, yet structured enough to maintain trust.
## Dynamic Path Design for Trusted AI
Fully autonomous "dynamic processes" are impressive, but in practice they often ignore the rulebook. Instead, I focus on **Dynamic Paths**, and they’re not the same thing.
Dynamic Paths are sequences of activities (capabilities) that AI intelligently assembles, considering all known constraints and dependencies. Once those are defined, a scoring model, driven by a **Business Rules Library**, prioritises paths based on factors such as end-to-end time, process cost, resource use, handover points, legislative requirements, and total processing time.
What makes Dynamic Paths a better fit than fully AI-powered "dynamic processes" in regulated industries comes down to two words: deterministic outcomes.
It’s similar to the "quality-of-life" approach in healthcare: focusing on sustained, measurable outcomes rather than reactive treatments. People commit to systems they can trust, and that trust is built on predictable, explainable results.
Unlike static processes, which represent a single prescribed view of how to support one use case, Dynamic Paths still operate within your organisation’s core capabilities, but assemble them into multiple contextual views, enabling customer-centric services that adapt intelligently without losing compliance or structure.
The key difference is that all this evaluation happens before any actions are executed with the client, empowering them to help shape and drive the service they want.
This is **Dynamic Path Orchestration**: adaptive automation that’s still explainable, governed, and safe.
## A Real-Life Story of Service Excellence (Before AI)
Before Agentic AI, I experienced first-hand what true service excellence looks like when human judgment, process discipline, and empathy come together.
A few years ago, while preparing a major client demonstration, my MacBook developed an intermittent screen fault that caused it to flicker, incredibly off-putting during presentations. One week before the meeting, the issue worsened, and I decided to get it fixed.
At Apple’s Sydney flagship store, in the middle of a new iPhone launch (in those days people queued for days), I learned there was a two-week wait just to see a technician. That was a deal breaker.
At the support desk was a specialist who eventually helped me, someone I call the "iPad guy." He wasn’t just a sales assistant; these front-of-house specialists are deeply trained across Apple’s entire operation: sales, support, and repair. They’re the people who bring everything together, translating between the customer’s needs and the company’s process constraints.
Initially, they tried to guide me down Apple’s standard "happy path", their prescribed best-practice process. For me, that would have meant:
- Scheduling a Genius appointment two weeks later
- Leaving the MacBook with Apple
- Them ordering the part only after drop-off
- Waiting another 5 to 10 business days for the repair
In total, a three to four week turnaround. Impossible with my upcoming deadline.
Apple’s Typical Customer Support Experience
I explained my situation: a business-critical deadline, loyal customer history, and no backup device. They listened, went backstage, and returned with a proposal I still remember as a masterclass in dynamic service design.
If I agreed to the path forward they would proactively order the part, let me keep the device until Friday, immediately schedule the repair for Saturday, and have it ready Sunday afternoon, complete with live progress updates through the Apple Support App.
**Revised turnaround time of less than 7 days, allowing me to have a great client meet.**
Success
It was adaptive, fair, and completely transparent: the essence of great orchestration.
## Bringing It All Together
Let’s bring the concept together and design an Apple-style support process powered by Dynamic Paths, showing how adaptive orchestration can co-exist with accountability.
### Start with the Approach
**Step 1: Understand all your capabilities.** Begin by identifying what you can actually do, not the sequence or ownership yet.
Example Breakdown of Capabilities
**Step 2: Identify constraints and dependencies.** Determine which capabilities can and can’t be sequenced together. Build a library of rules, policies, and best practices, your Business Rules Library.
**Step 3: Use AI to sequence capabilities into valid paths.** Leverage Agentic AI to intelligently assemble allowable combinations into end-to-end Dynamic Paths.
**Step 4: Apply scoring logic.** Use a scoring model to assess each path, weighing pros and cons such as cost, turnaround time, compliance exposure, and customer impact.
**Step 5: Present and validate.** Share the top paths with management (for large deviations) or directly with clients (for smaller variations).
**Step 6: Client sign-off and execution.** Once a path is agreed upon, it becomes the living process instance, executed with transparency, governance, and monitoring.
### Map Capabilities to BOAT
Each step aligns to the layers of Business Orchestration and Automation Technologies (BOAT), the foundation for implementing Dynamic Paths in real enterprise environments:
Dynamic Path Components → BOAT Capabilities
> **Note:** This table is illustrative. Many of the organisations mentioned provide solutions spanning multiple BOAT layers, and the exact mapping will vary by architecture and use case.
### Visualise the To-Be Process
Finally, bring it all together in a Dynamic Path Orchestration diagram, showing how AI and orchestration layers combine to deliver adaptive, compliant service flows.
A Possible AI-Powered V2 of Apple’s Customer Support, showcasing a "Dynamic Paths" Approach
## Final Thoughts
By designing automation around Dynamic Paths, capability libraries, and governance rules, organisations can achieve adaptivity without chaos and compliance without stagnation.
If your organisation is exploring Dynamic Path Orchestration, capability libraries, or the integration of Agentic AI into existing BOAT frameworks, reach out. I’m happy to share practical models and lessons learned from across the leading BOAT ecosystem.
---
# Agentic AI with Camunda and ChatGPT: An Insurance Claims Tutorial
URL: https://goldenpassport.blog/blog/agentic-ai-camunda-chatgpt-insurance-tutorial
Date: 2025-06-27
Category: Tech
Tags: Agentic AI, Camunda, ChatGPT, RAG, BPM, Process Automation, InsuranceTech, Open Source
Originally published at: https://www.linkedin.com/posts/lukeaudie_agenticai-camunda-chatgpt-share-7339250975896915969-SiD8/
> A hands-on end-to-end Insurance Claims tutorial that brings Agentic AI concepts together with Camunda 8 and ChatGPT, kicking off a series on process-driven, enterprise-ready AI.
Just released a hands-on tutorial showcasing a simple end-to-end Insurance Claims process that brings together several core Agentic AI concepts, combining leading tools in process orchestration (Camunda) and large language models (ChatGPT).
If you’re technically minded, work in a regulated industry like financial services (which often struggles with AI adoption), or simply haven’t had the right opportunity to roll up your sleeves with AI, this is the perfect place to start.
This tutorial kicks off a broader series on **"Process-driven Agentic AI"**, focused on going beyond the hype to explore how AI can be operationalised in structured, enterprise-ready ways.
## In this tutorial, you’ll see
- **Image classification** of insurance claims using ChatGPT
- **Retrieval-Augmented Generation (RAG)** to reference policy terms
- **Agent-style decision-making** via structured prompts and JSON
- **Full orchestration** in Camunda 8 (no Docker required)
This isn’t about "playing with new toys". It’s about pragmatic, responsible AI adoption in real business workflows. In future tutorials, we’ll go hands-on with:
- **Private LLMs and data sovereignty**
- **Enterprise-scale readiness and governance**
- **Turning AI into business value, not just clever demos**
## Let’s talk
I’ll be hosting both recorded and in-person sessions soon. Always happy to connect if:
- You’re exploring Agentic AI in your processes
- You’re trying to scale AI inside a regulated business
- Or you just want to bounce ideas
[Drop me a message.](/contact)
---