{"id":94,"date":"2026-07-14T18:29:51","date_gmt":"2026-07-14T18:29:51","guid":{"rendered":"https:\/\/oliverng.com\/ai\/?p=94"},"modified":"2026-07-14T18:54:56","modified_gmt":"2026-07-14T18:54:56","slug":"a-day-of-claude-workflows","status":"publish","type":"post","link":"https:\/\/oliverng.com\/ai\/2026\/07\/14\/a-day-of-claude-workflows\/","title":{"rendered":"A day of Claude workflows"},"content":{"rendered":"\n

I tried to come up with a scenario to try out Claude Dynamic Workflows<\/a>, a deterministic way to manage processes for subagents. Claude recommends you use them for large scale activities that benefit from multiple agents. I wanted to understand how it is different from Claude Agent Teams<\/a>, which, is easy to forget also<\/em> exists.<\/p>\n\n\n\n

One noticeable difference, is that agent teams shares context within the group. Workflow agents do not and act independently on the prompt. Workflows are also programmatic. Their sequence of actions are managed through python code + prompts. This allows you to deterministically define workflow and results.<\/p>\n\n\n\n

I thought it would be fun to take advantage of this knowledge and use it as a way for AI to reason about security risk. <\/p>\n\n\n\n

A common argument in Cybersecurity, is risk. You have a vulnerability, we have to quantify the risk. Not always trivial. Fights ensue. People say that it will never happen. They say the architecture does not allow it. They say controls exist. Everyone comes with their independent views. I took these horrible memories of my career, and built an agent workflow that could debate risk<\/strong> – in hopes I would never have to live it again. <\/p>\n\n\n\n

Kidding aside, it was a fun experiment. LLMs are great at grounding themselves into a specific viewpoint, taking context, and providing a result. So I made a roundtable of tech personalities that can repeatedly play out my worst nightmares.<\/p>\n\n\n\n

<\/p>\n\n\n\n

The Panel<\/h2>\n\n\n\n

The roles I chose were a Security Analyst, a Business Owner, and an Architecture Lead. These three signify typical friction I’ve seen where each debate from their own area of accountability. <\/p>\n\n\n\n

    \n
  • Security Analyst<\/strong>: Argues for stronger controls and higher severity where evidence supports it. Accountable for what happens if the risk is realized. They are normalized by ensuring they are not simply debating that all risk is critical risk but to be defensible and grounded.<\/li>\n<\/ul>\n\n\n\n
      \n
    • Business \/ Product Owner<\/strong>: Optimizes for time-to-market, user friction, and opportunity cost. Argues for acceptance, deferrals, or compensating controls. Accountable for the cost of not shipping, including security costs of users staying on worse legacy systems.<\/li>\n<\/ul>\n\n\n\n
        \n
      • Architecture<\/strong>: What can be built and run, and what each control costs in complexity, blast radius, and operational burden. Often the tie-breaker \u2014 surfaces that a control Security wants may be infeasible as stated but achievable in another form.<\/li>\n<\/ul>\n\n\n\n

        I thought it would be interesting to have additional roles that clean up the debate and tie-break. <\/p>\n\n\n\n

          \n
        • Chair<\/strong>: Summarize key debate items. Takes no side. Translates the risk debate items from technical language into common human language. This Chair will help summarize the “agent talk” so that I can understand what’s being said and debated.<\/li>\n<\/ul>\n\n\n\n
            \n
          • Skeptic<\/strong>: Acts to be “that guy” that only has negative things to say. Will debate the specific controls, proposals, risks to find counter-points against the role proposing the item. It reinforces a sanity check to re-think on ideas. Protects against LLM “making stuff up and confirming their own behaviour”. Adds rigor to analysis.<\/li>\n<\/ul>\n\n\n\n

            <\/p>\n\n\n\n

            The workflow<\/h2>\n\n\n\n

            When running the workflow, the idea is to provide a risk statement to the panel. As with all LLMs, the more context, the better. I provide a scenario, describing the system, then provide a security finding and recommendation. It’s like an everyday scenario, where a security guy walks into a room with the product team and goes over findings. I gave it something like below (shortened).<\/p>\n\n\n\n

            Scenario: a cloud-native multi-tenanted SaaS product, generates customer reports with regulated PII, and store these reports in a cloud storage container.

            Risk Question: A control requiring tenant-wide customer-managed keys (CMK) is not in place.  Should we block the product team from going live with platform-managed keys, or risk-accept it.<\/pre>\n\n\n\n
            I like this question because I find the use of CMK contentious. It is one of those items where so many people feel it is over-engineering security, given that we are encrypting encrypted data. But everyone typically agrees that a regulatory bodies will not accept that a “platform” holds your encryption key and is a party to the regulated data.<\/p>\n\n\n\n
            The workflow ran and the outcome of the Agent debate was entertaining.<\/p>\n\n\n\n
            \n\n\n\n

            Security.  Block.  

            Rationale: One key compromise = full tenant exposure in a regulated industry.  At least block until production team  commits to implementation date.

            Trade-off: Understands CMK is ops work, but won't back down due to regulated data.
            <\/pre>\n\n\n\n
            \n\n\n\n
            Business. Accept.

            Rationale: Revenue is blocking on go-live.  Feels this is a LOW risk as platform managed key still encrypts data at rest.  Referenced a compensating control of customer having a contract in place, IP-allowlisting, per-customer tokens and 24h data purge.

            Trade-off: Delayed revenue for a quarter, acknowledged case relies on allow-listing to be implemented per customer as contract states.<\/pre>\n\n\n\n
            \n\n\n\n
            Architecture. Partial. Tie-break.

            Rationale: Agrees with security but agrees with product that while tenant-wide CMK is not feasible in the time period, an alternative of store specific CMK is doable.

            Trade-off: PMK acceptance today will be costly later down the line with full CMK.<\/pre>\n\n\n\n
            \n\n\n\n
            I love this.  <\/strong><\/p>\n\n\n\n
            It is like playing The Sims, watching agents argue with each other about my typical security life.  Except I have zero stakes in the discussion. <\/p>\n\n\n\n
            Seeing the arguments reflected in appropriate standpoints shows me how I can use LLMs to help iterate on decisions and be more open minded in my analysis.  There’s more and this is where the role of the skeptic and chair come in.<\/p>\n\n\n\n
            \n\n\n\n
            Skeptic.  Refute the lowering of risk.

            Rationale: States that there is no proof that the allow-list is in place.  The product agent stating that the risk is lowered, as a compensating control, is unproven.  The panel needs to demonstrate the allow-list is in place with configuration evidence.<\/pre>\n\n\n\n
            \n\n\n\n
            Chair.

            Surfaced: the allow-list is a contentious issue and will change the risk between a medium vs high.  It should be confirmed.

            Proposal: Recommend CMK on the storage today, with full CMK later. Architecture's proposal is a good middle ground.<\/pre>\n\n\n\n
            \n\n\n\n
            I like how the skeptic played its role in calling out a common scenario where teams will say “Well, we have this in place.” and then security to say “Show me.  I didn’t see that in my data.”  And the chair also played its role in not providing a stance, but to give that “management view” of analyzing the whole debate and saying, well this makes sense, this is the pragmatic recommendation.<\/p>\n\n\n\n
            The table the workflow generated as a summary.  A nice touch was it generated a new security requirement too:<\/p>\n\n\n\n
            Summary<\/td>Do not accept PMK as-is. Take Architecture’s middle path: enable CMK on the export store now, and defer only per-tenant key isolation. 

            The risk is High today because the likelihood-reducing controls Business proposed are unverified.<\/td><\/tr>
            Rating<\/td>High \u2013 likelihood Medium x impact High. Would drop to Medium only if the IP allow-list enforcement is confirmed.<\/td><\/tr>
            Recommended decision<\/td>Mitigate by compensating control (CMK-on-store + SAS + 24h purge) now; defer per-tenant key isolation to next quarter.<\/td><\/tr>
            REQ-NEW <\/td>Export store must enforce IP allow-listing.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
            <\/p>\n\n\n\n
            I should add that I added a risk rating rubric to ensure that risks were following a standard and deterministic method.  The Agent Workflow is programmed to use this rubric when evaluating risk across all sub-agents.<\/p>\n\n\n\n
            Closing Thoughts<\/h2>\n\n\n\n
            Long post. I really enjoyed this experiment.  There is a lot more that can be done here too.  We could have additional agents that go out and search for real-world examples of security issues being debated, CVEs, more personas, etc.<\/p>\n\n\n\n
            Finally, I should add that while this was an experiment for Claude Workflows, Agent Teams can also execute the same task.  In fact, my workflow allows for both a “Quick” mode using Agent Teams and a “Full” mode using Workflows.<\/p>\n\n\n\n
            Agent teams, will use:<\/p>\n\n\n\n
              \n
            • shared context <\/li>\n\n\n\n
            • parallel agents<\/li>\n\n\n\n
            • repeatable via best-effort basis <\/li>\n\n\n\n
            • recommended output formats.<\/li>\n\n\n\n
            • cheaper<\/li>\n<\/ul>\n\n\n\n
              Workflows, will use: <\/p>\n\n\n\n
                \n
              • separate agent contexts<\/li>\n\n\n\n
              • structural independence <\/li>\n\n\n\n
              • deterministic, auditable, repeatable <\/li>\n\n\n\n
              • dedicated agent pass by the skeptic <\/li>\n\n\n\n
              • outputs enforced by schema.<\/li>\n\n\n\n
              • expensive, as it will spawn multiple agents + overhead orchestration agents<\/li>\n<\/ul>\n\n\n\n
                <\/p>\n\n\n\n
                The auditable part of Claude Workflows is unique.  Workflows give you a structured run journal, that provides a view of exactly what was done and when, compared to agent teams, that only provides a conversation.<\/p>\n\n\n\n
                Workflows is more costly.  My experimenting on Opus 4.8 has shown about 35% cost overhead but depending on how important having a deterministic, agent orchestrated run is to you, that may be acceptable.<\/p>\n\n\n\n
                <\/pre>\n","protected":false},"excerpt":{"rendered":"
                I tried to come up with a scenario to try out Claude Dynamic Workflows, a deterministic way to manage processes for subagents. Claude recommends you use them for large scale activities that benefit from multiple agents. I wanted to understand how it is different from Claude Agent Teams, which, is easy to forget also exists. […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[],"class_list":["post-94","post","type-post","status-publish","format-standard","hentry","category-experimenting"],"_links":{"self":[{"href":"https:\/\/oliverng.com\/ai\/wp-json\/wp\/v2\/posts\/94","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/oliverng.com\/ai\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/oliverng.com\/ai\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/oliverng.com\/ai\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/oliverng.com\/ai\/wp-json\/wp\/v2\/comments?post=94"}],"version-history":[{"count":27,"href":"https:\/\/oliverng.com\/ai\/wp-json\/wp\/v2\/posts\/94\/revisions"}],"predecessor-version":[{"id":161,"href":"https:\/\/oliverng.com\/ai\/wp-json\/wp\/v2\/posts\/94\/revisions\/161"}],"wp:attachment":[{"href":"https:\/\/oliverng.com\/ai\/wp-json\/wp\/v2\/media?parent=94"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/oliverng.com\/ai\/wp-json\/wp\/v2\/categories?post=94"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/oliverng.com\/ai\/wp-json\/wp\/v2\/tags?post=94"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}