Genesys Cloud - Developer Community!

I've been building out the tooling/processes to allow Claude Code to reliably build, deploy & test Architect flows. 

I shared more details in a LinkedIn post, but thought I'd share more specific decisions here.

My aim is to create a process and the utilities to enable Claude Code to iterate on flows with you, help find issues/optimisations or even create automated test plans etc.

These are two decisions I've made so far:

Using Architect Scripting SDK over Archy

I found the YAML representation of flows that Archy deploys to be very verbose, which along with deployment logs & internal thoughts lead to the context filling quickly.

The lack of a specification for the flow's YAML meant Claude Code had to try and deploy the YAML to find any issues.

Architect Scripting SDK to the rescue

This SDK allows flows to be defined as code (with types too), which I believe is then used to derive the YAML definition. Being code accompanied by types allows me to dramatically reduce the turnaround time between defining a flow and successfully deploying it.

Complex flows can also be split across files, limiting what is loaded into the context.

There is a downside though: The SDK can either update or recreate flows, with the latter being easier for Claude Code. This means any references to the flow need to be detached before making a change, then reattached afterwards - I have created tooling for this.

Favouring my testing tools

I am getting it to rely on my free WM tester and IVR Tester tools. Although I realise other tooling is available, I just don't have access to it.

Requiring OAuth Client

I started simple, which means setting up Architect Scripting SDK with a OAuth Client Credentials. This means I can limit the permissions Claude Code has to interact with the system via a custom role.

--

See a limitation or oversight? I've love to know, as I am continuing to build this process out.

#Architect
#Archy
#CXasCode
#PlatformAPI

------------------------------
Lucas Woodward
Winner of Orchestrator of the Year, Developer (2025)

LinkedIn - https://www.linkedin.com/in/lucas-woodward-the-dev
Newsletter - https://makingchatbots.com
------------------------------

Really interesting direction, Lucas.

I think one of the biggest hidden challenges here is not only generating flows, but creating deterministic and safe deployment behavior for production environments.

Your point about the Architect Scripting SDK versus raw Archy/YAML makes a lot of sense. The typed/code-driven approach is probably much more AI-friendly long term because LLMs perform significantly better when there is stronger structural guidance and validation before deployment.

One thing I would strongly consider is introducing an intermediate validation/governance layer before deployment, especially for enterprise environments.

For example, automatically validating things like:

• unreachable tasks
• missing disconnect paths
• recursive loops
• missing error handling
• Data Actions without timeout/failure branches
• transfer blocks without fallback routing
• prompt reuse inconsistencies
• variable explosion/context bloat
• queue/audio dependency validation

Because one thing I'm noticing with AI-generated Architect logic is that flows may be syntactically valid but operationally fragile.

Another area that becomes extremely important is observability.

Once AI starts generating/modifying flows dynamically, troubleshooting becomes harder unless you also generate:

• deployment diffs
• flow topology snapshots
• execution tracing metadata
• automated regression simulations
• rollback references

I also think your OAuth approach is the correct one. Narrow-scoped machine identities with custom roles are probably essential if people eventually allow autonomous modifications in production-adjacent orgs.

One possible future issue to watch for:
Architect itself has many implicit operational behaviors that are difficult for LLMs to fully infer from configuration alone, especially around:

• routing behavior
• queue interactions
• participant data lifecycle
• transfer semantics
• channel-specific limitations
• bot/runtime edge cases

So I suspect long-term success here may depend less on "flow generation" and more on building strong domain-specific guardrails and validation intelligence around the generation process.

Very promising work overall. This is probably one of the most interesting CX-as-Code directions happening right now in the Genesys ecosystem.

------------------------------
Gabriel Garcia
NA
------------------------------

Hi Gabriel,

Thank you for your response, you make some great points!

If you don't mind when I create the GitHub repo for this project I'll add your lists as Issues, to remind me of scenarios to investigate - with credit given to you in each of them of course.

Improving Claude's ability to troubleshoot issues will be an interesting one! Hopefully, if implemented correctly it may offer an opportunity for people to use Claude to troubleshoot existing flows too.

My starting point for troubleshooting will be to see how far I can get with flow executions, however I suspect there will be a lot of work involved to make the response easily understood by Claude.

Have you had experience with flow topology snapshots? I would love to see what the community is doing with diagramming/documenting flows outside of Genesys Cloud.

------------------------------
Lucas Woodward
Winner of Orchestrator of the Year, Developer (2025)

LinkedIn - https://www.linkedin.com/in/lucas-woodward-the-dev
Newsletter - https://makingchatbots.com
------------------------------

Original Message:
Sent: 05-13-2026 16:44
From: Gabriel Garcia
Subject: Progress creating Architect Flows with Claude Code

Really interesting direction, Lucas.

I think one of the biggest hidden challenges here is not only generating flows, but creating deterministic and safe deployment behavior for production environments.

Your point about the Architect Scripting SDK versus raw Archy/YAML makes a lot of sense. The typed/code-driven approach is probably much more AI-friendly long term because LLMs perform significantly better when there is stronger structural guidance and validation before deployment.

One thing I would strongly consider is introducing an intermediate validation/governance layer before deployment, especially for enterprise environments.

For example, automatically validating things like:

• unreachable tasks
• missing disconnect paths
• recursive loops
• missing error handling
• Data Actions without timeout/failure branches
• transfer blocks without fallback routing
• prompt reuse inconsistencies
• variable explosion/context bloat
• queue/audio dependency validation

Because one thing I'm noticing with AI-generated Architect logic is that flows may be syntactically valid but operationally fragile.

Another area that becomes extremely important is observability.

Once AI starts generating/modifying flows dynamically, troubleshooting becomes harder unless you also generate:

• deployment diffs
• flow topology snapshots
• execution tracing metadata
• automated regression simulations
• rollback references

I also think your OAuth approach is the correct one. Narrow-scoped machine identities with custom roles are probably essential if people eventually allow autonomous modifications in production-adjacent orgs.

One possible future issue to watch for:
Architect itself has many implicit operational behaviors that are difficult for LLMs to fully infer from configuration alone, especially around:

• routing behavior
• queue interactions
• participant data lifecycle
• transfer semantics
• channel-specific limitations
• bot/runtime edge cases

So I suspect long-term success here may depend less on "flow generation" and more on building strong domain-specific guardrails and validation intelligence around the generation process.

Very promising work overall. This is probably one of the most interesting CX-as-Code directions happening right now in the Genesys ecosystem.

------------------------------
Gabriel Garcia
NA
------------------------------

That would be great, Lucas - feel free to use them.

And honestly, I think troubleshooting existing flows may become even more valuable than pure flow generation itself. Most enterprise environments already have hundreds of flows, years of technical debt, inconsistent standards, and very little documentation consistency.

One thing I've seen help a lot for topology/documentation outside Genesys is treating Architect almost like distributed workflow infrastructure rather than only IVR logic.

The most useful representations I've seen usually combine:

• flow dependency graphs

• transfer/routing maps

• Data Action relationships

• queue dependencies

• reusable task/component mapping

• failure/fallback visualization

because operationally, the "real" architecture is usually spread across multiple interconnected flows rather than inside a single flow.

For topology snapshots specifically, I've seen some teams generate:

• Mermaid diagrams

• Graphviz/network graphs

• JSON relationship maps

• node/edge execution graphs
  from exported flow metadata and API inventorying.

One thing that may become extremely valuable for AI troubleshooting is creating a normalized intermediate representation of Architect flows before giving them to Claude.

Something like:

• intent

• routing behavior

• failure paths

• dependencies

• state transitions

• external integrations

• retry logic
  instead of exposing the raw deployment structure directly.

Because one major challenge with Architect is that the implementation detail is often much noisier than the actual operational logic.

I also suspect historical execution telemetry will become critical eventually. The moment you combine:

• topology

• execution paths

• transfer outcomes

• error frequency

• abandonment patterns

• loop detection

• retry behavior

you move from "AI flow generation" into something much closer to autonomous CX optimization and operational diagnostics.

That is where this space starts becoming really interesting.

------------------------------
Gabriel Garcia
NA
------------------------------

Original Message:
Sent: 05-14-2026 16:37
From: Lucas Woodward
Subject: Progress creating Architect Flows with Claude Code

Hi Gabriel,

Thank you for your response, you make some great points!

If you don't mind when I create the GitHub repo for this project I'll add your lists as Issues, to remind me of scenarios to investigate - with credit given to you in each of them of course.

Improving Claude's ability to troubleshoot issues will be an interesting one! Hopefully, if implemented correctly it may offer an opportunity for people to use Claude to troubleshoot existing flows too.

My starting point for troubleshooting will be to see how far I can get with flow executions, however I suspect there will be a lot of work involved to make the response easily understood by Claude.

Have you had experience with flow topology snapshots? I would love to see what the community is doing with diagramming/documenting flows outside of Genesys Cloud.

------------------------------
Lucas Woodward
Winner of Orchestrator of the Year, Developer (2025)

LinkedIn - https://www.linkedin.com/in/lucas-woodward-the-dev
Newsletter - https://makingchatbots.com
------------------------------


Original Message:
Sent: 05-13-2026 16:44
From: Gabriel Garcia
Subject: Progress creating Architect Flows with Claude Code

Really interesting direction, Lucas.

I think one of the biggest hidden challenges here is not only generating flows, but creating deterministic and safe deployment behavior for production environments.

Your point about the Architect Scripting SDK versus raw Archy/YAML makes a lot of sense. The typed/code-driven approach is probably much more AI-friendly long term because LLMs perform significantly better when there is stronger structural guidance and validation before deployment.

One thing I would strongly consider is introducing an intermediate validation/governance layer before deployment, especially for enterprise environments.

For example, automatically validating things like:

• unreachable tasks
• missing disconnect paths
• recursive loops
• missing error handling
• Data Actions without timeout/failure branches
• transfer blocks without fallback routing
• prompt reuse inconsistencies
• variable explosion/context bloat
• queue/audio dependency validation

Because one thing I'm noticing with AI-generated Architect logic is that flows may be syntactically valid but operationally fragile.

Another area that becomes extremely important is observability.

Once AI starts generating/modifying flows dynamically, troubleshooting becomes harder unless you also generate:

• deployment diffs
• flow topology snapshots
• execution tracing metadata
• automated regression simulations
• rollback references

I also think your OAuth approach is the correct one. Narrow-scoped machine identities with custom roles are probably essential if people eventually allow autonomous modifications in production-adjacent orgs.

One possible future issue to watch for:
Architect itself has many implicit operational behaviors that are difficult for LLMs to fully infer from configuration alone, especially around:

• routing behavior
• queue interactions
• participant data lifecycle
• transfer semantics
• channel-specific limitations
• bot/runtime edge cases

So I suspect long-term success here may depend less on "flow generation" and more on building strong domain-specific guardrails and validation intelligence around the generation process.

Very promising work overall. This is probably one of the most interesting CX-as-Code directions happening right now in the Genesys ecosystem.

------------------------------
Gabriel Garcia
NA

If you run archy refresh, you get a lot of JSON schema files. Why don't those serve as a specification?

------------------------------
Regards,

Russell Hanneken
------------------------------