Genesys Cloud - Developer Community!

 View Only

Sign Up

  • 1.  Progress creating Architect Flows with Claude Code

    Posted yesterday
      |   view attached

    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
    ------------------------------


  • 2.  RE: Progress creating Architect Flows with Claude Code

    Posted 2 hours ago

    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
    ------------------------------

    Original Message


Related Content