Coder Legion - Recent posts tagged orchestration

Introducing AIWorkHub: a repository-native control plane for AI coding agents

Fri, 31 Jul 2026 10:08:41 +0000

Suggested canonical URL: https://github.com/shrec/AIWorkHub

Meta description: AIWorkHub is an open-source, local-first VS Code control
plane for planning, delegating and reviewing software-development tasks across
multiple AI coding models without giving up repository authority.

AI coding tools are increasingly capable, but coordinating more than one of
them still feels improvised. A task is copied into a chat, context is scanned
again, a worker changes files, and the result is accepted because the model
says it is finished. The conversation, evidence and project state are often
scattered across tools.

I built AIWorkHub to turn that workflow into a repository-owned engineering
system.

AIWorkHub is an open-source, local-first control plane for multi-model software
development in VS Code. It gives each Git repository its own task queue, code
index, durable context, worker isolation, evidence bundles and manager review
loop. It works with model routes already available through VS Code or their
authenticated CLIs, rather than moving project authority into an AIWorkHub
cloud service.

The project is available under the MIT License:

https://github.com/shrec/AIWorkHub

The problem is coordination, not another chat box

Once several coding agents participate in a project, the hard questions are no
longer only about generation quality:

Which task is ready, and which one is blocked by another change?
Which model is appropriate for the work and currently available?
What files may a worker modify?
Did the worker use the repository's approved context tools throughout the
task, or fall back to repeatedly scanning the tree?
Which tests, diffs and artifacts support the claimed result?
Who accepts the result and updates canonical project state?
How do callbacks return to the correct manager, repository and chat?
What survives a reload, a long session or context compaction?

AIWorkHub treats these as control-plane concerns. The model remains useful for
reasoning and implementation, while deterministic software owns identity,
routing, state transitions, isolation and evidence.

One isolated workspace per repository

After explicit initialization, AIWorkHub creates a repository-local
.aiworkhub/ state directory. Tasks, callback records, indexes, sessions,
memories, knowledge entries and audit evidence belong to that repository.

There is no shared project database and no AIWorkHub HTTP service. The VS Code
extension communicates with a repository-bound MCP runtime over stdio. This
keeps two projects open in two editor windows from silently sharing task state
or context.

The same verified manager chat can switch between live repositories by stable
repository identity. The selected repository changes; the manager thread does
not need to be recreated for every project.

A task lifecycle with a real review boundary

AIWorkHub models work as dependency-aware task cards. A card can declare:

its objective and acceptance criteria;
the runner and model route;
allowed write paths and forbidden actions;
dependencies and collision constraints;
required outputs and validation commands.

Workers run in bounded workspaces. A completed process does not silently become
an accepted change: it enters review with its terminal status and evidence. The
manager can inspect the diff, tests, logs, artifacts, validation history and
tool-use receipts, then accept the change or return a precise residual for
rework.

That distinction matters. "The agent finished" and "the repository accepted
the change" are different events.

Source intelligence instead of repeated tree scans

AIWorkHub maintains an automatically refreshed Source Graph for the active
repository. Managers and workers can request bounded structural context instead
of repeatedly rediscovering the codebase with broad filesystem scans.

The goal is not to publish an unverifiable "tokens saved" number. AIWorkHub
records context evidence: what was requested, what was delivered, what the
worker acknowledged, whether content was truncated and why a route degraded.
This makes context efficiency measurable without pretending that bytes are
automatically tokens or dollars.

Source Graph usage is part of the task evidence, so teams can measure whether
agents use the intended code-intelligence path throughout their work rather
than only mentioning it at the start of a prompt.

Durable context has more than one job

AIWorkHub deliberately separates several context authorities:

Session Manager holds current execution state, checkpoints and handoffs.
AI Memory stores reusable decisions and lessons with lifecycle state.
Knowledge Base stores curated project contracts and authoritative facts.
Source Graph provides bounded structural code intelligence.
Manager Context Graph optionally preserves exact completed manager-chat
evidence and deterministic links between repositories, threads, sessions,
tasks, actors and events.

The Context Graph is a recovery layer, not an automatic policy engine. A past
conversation can explain why a decision was made; it does not silently override
the current knowledge base or task contract. Current passive capture supports
completed Codex user and assistant messages. It excludes reasoning, streaming
deltas, tool output, commands and approval prompts.

Multi-model routing without copying credentials

AIWorkHub can route work to Codex, Claude, DeepSeek, GLM and models exposed by
the VS Code Language Model API, depending on what is installed and authorized
on the user's machine.

Editor routes use models already visible in VS Code and ask for the editor's
normal one-time model consent. CLI routes reuse that CLI's authenticated
session. AIWorkHub does not copy editor or CLI credentials into the repository.

Availability is discovered at runtime because subscriptions and model catalogs
differ. A preflight surface reports which adapters are installed, authorized
and launchable before a task is claimed.

Safety is part of the architecture

Autonomous coding needs narrow authority. AIWorkHub includes:

separate write and process-launch gates, both disabled by default;
shell-free exact-task launches;
explicit allowed-write scopes;
isolated worker workspaces and Landlock where available;
owner-only credentials outside repositories;
secret-redacted logs;
durable callback delivery with lease, retry and deduplication;
fail-closed repository, manager, task and claim identity checks;
append-only audit evidence and authenticated tool-use receipts.

The manager keeps acceptance authority. Launched workers do not inherit the
manager's ability to launch more workers.

The dashboard

The AIWorkHub VS Code dashboard exposes the task queue, dependency state,
review inbox, live output, callback health, adapter preflight, storage usage,
Source Graph status and repository context stores. It opens as an editor tab so
the orchestration surface can sit beside code and model chats.

AIWorkHub is also self-hosted in the practical sense: its own development can
be planned, delegated and reviewed through an AIWorkHub repository instance.

Install it

The current public distribution channel is a GitHub Release VSIX. Marketplace,
Open VSX and PyPI publication are planned but are not live yet.

Download aiworkhub-*.vsix from the
latest release.

Install it:

code --install-extension aiworkhub-*.vsix

Open a Git repository in VS Code.
Run AIWorkHub: Open Dashboard.
Choose Initialize AIWorkHub once.
Open a new model chat so it discovers the repository MCP tools.

The packaged extension is qualified for Linux, macOS, native Windows, WSL and
Remote-SSH. Initialization is explicit and idempotent; it creates the local
stores and starts the first Source Graph index.

What comes next

The engineering foundation is in place, but this is still an early open-source
release. The near-term work is focused on distribution, provider-independent
callback qualification, richer visual planning, historical reliability
analytics and making context economics easier to inspect.

If this direction is useful to you, try the release on a non-critical
repository, read the security model before enabling launches, and share the
rough edges you find.

Repository: https://github.com/shrec/AIWorkHub
Releases: https://github.com/shrec/AIWorkHub/releases
License: MIT

Thanks to null0xxx for sharing
kimi-atlas and useful ideas about
multi-agent orchestration and evidence-driven verification.

AI-SLOP-DETECTOR v3.8.1: When Code Generation Gets Cheap, Structural Trust Gets Expensive

Fri, 05 Jun 2026 16:30:58 +0000

For a long time, the hardest part of software development was writing code.

That is no longer true.

As AI-assisted coding and agent-driven workflows become mainstream, the cost of generating code is collapsing. But the cost of understanding, reviewing, simplifying, and deleting code is rising just as quickly. Code is now easier to append than to validate. Easier to duplicate than to consolidate. Easier to generate than to safely remove.

That asymmetry is creating a new engineering problem. The question is no longer only:

How do we generate more code faster?

It is increasingly:

How do we stop generated code from silently degrading the structure of a codebase?

That is the space AI-SLOP-DETECTOR is being built for.

v3.8.1 matters because the project is moving from detection toward governed cleanup, while keeping three layers separate:

scoring: measure structural risk
action planning: prioritize what is safe or important to review
enforcement: verify what must fail closed

That separation is the real story of this release. It is also the strongest reason to take the project seriously.

Why This Release Matters Now

There are many tools that claim to measure “AI code quality.” The meaningful distinction is not whether they can emit findings. It is whether they preserve boundary discipline when the findings start to drive workflow.

v3.8.1 is important because it sharpens three claims:

The scoring path became safer
Cleanup became more actionable
Governance became harder to bypass

Everything else in this release is evidence for one of those three claims.

Changelog Evidence Since v3.6.0

The recent releases make more sense as a sequence than as isolated feature drops.

Version	Key Change	Why It Mattered
`v3.6.0`	Claude Code Skill, CI gate fix, pre-commit rewrite, VS Code packaging	The project became more workflow-aware, not just scan-aware
`v3.7.0`	Dogfooding calibration, renderer/module splits, self-repair from internal audit	Maintainability and internal trust improved
`v3.7.1`	False-positive reduction, richer skill routing, VS Code modularization	Lower friction and better usability
`v3.7.2`	Config/schema validation and runtime data guards	The scoring path became harder to corrupt
`v3.7.3`	Import/package stability and CI fixes	The tool became more reliable in real environments
`v3.7.4`	Major false-positive patch wave	Trustworthiness improved materially
`v3.7.5`	`phantom_import` flat-project fix	A visible correctness gap was closed
`v3.7.6`	`deficit_breakdown`, idempotent `--init`, first-run UX improvements	Explainability and onboarding improved
`v3.7.7`	Cross-language aggregation fix, ignore matching fix, ML reproducibility fix	Project-level correctness improved
`v3.7.8`	Structural scaling, suppression ledger, cache, hotspots, agent API	The tool became more operational
`v3.7.9`	Governance verification gate and math/policy separation	Enforcement became explicit and fail-closed
`v3.8.0`	Canonical CLI: `scan / review / pulse / sweep`	The public surface became simpler and more stable
`v3.8.1`	Cleanup confidence planning, manifest hygiene, layered architecture review	The tool moved from issue listing toward action planning

Seen together, these releases show a pattern: not just more features, but more correctness, more explainability, more governance, and more usable workflow surfaces.

Claim 1: The Scoring Path Became Safer

The most important technical reinforcement since v3.6.0 is not that the project added more signals. It is that the project made the scoring path safer to trust.

The core model still uses a weighted geometric aggregation across four dimensions:

with the deficit-oriented score driven by:

Here, P pattern represents the additional penalty assigned when repeated structural patterns reinforce the deficit.

That formula is not the interesting part by itself. The important part is what was reinforced around it.

What changed

config values are validated before they enter the model
metric ranges are guarded before they can poison the score
deficit_breakdown makes score attribution inspectable
cross-language aggregation no longer misstates project summaries
structural coherence now scales with deterministic fallback above a ceiling

Why it matters

Without those reinforcements, the formula risks becoming authority texture. With them, it behaves more like an engineering instrument.

For a technical reader, the observable improvement is not abstract math prestige. It is:

fewer broken summaries
fewer config-induced distortions
better explanation of where a score came from
predictable behavior on large repositories

In short, the model became harder to misuse, easier to explain, and more stable at scale.

Claim 2: Cleanup Became More Actionable

Most code-quality tools stop at issue emission. That is useful, but incomplete.

Developers do not only need to know what exists. They need to know:

what is important
what is probably safe to review
what needs human caution
what should be looked at first

That is where v3.8.1 makes its clearest product-level leap.

Cleanup confidence planning

Cleanup-family outputs can now carry:

confidence
action_class
evidence

The important architectural choice is that this was not implemented as a second disconnected scoring model. Cleanup confidence is a reuse layer over existing signals:

deficit_score
churn
coverage gap
cleanup-local evidence

A simplified mental model looks like this:

confidence = base_evidence
confidence += low_churn_bonus
confidence += low_coverage_bonus
confidence -= active_churn_penalty

The exact arithmetic is less important than the architecture: the system is not maintaining one truth model for scoring and another truth model for cleanup.

Manifest-aware dependency hygiene

unused-deps also grew beyond file-local hints. It now reads:

pyproject.toml
package.json

and can emit:

manifest_unused_dependency
undeclared_import

That matters because many dependency problems are not visible inside a single file. They exist at the boundary between source code and project metadata.

Why it matters

Before:

sweep -> list of candidates

After:

sweep -> ranked issues -> action class -> evidence-backed review plan

That is the difference between a detector and a cleanup instrument.

Claim 3: Governance Became Harder To Bypass

This is arguably the article’s strongest credibility anchor, and it deserves to be said plainly:

The project does not ask the score to become policy, and it does not let policy quietly mutate the score.

That is the right architectural judgment.

What changed

The project now treats governance as a separate fail-closed path:

analysis emits a deterministic governance artifact
verification recomputes the artifact hash
policy checks run in a dedicated verification gate

The workflow is intentionally layered:

analysis -> governance_record.json -> verify-governance -> pass/fail enforcement

Why it matters

This separation means:

math can evolve without silently changing CI policy
policy can become stricter without corrupting the scoring model
governance can be audited as an artifact, not just inferred from a transient report

In a category crowded with vague “AI code quality” claims, this is the kind of subsystem separation that actually signals seriousness.

Supporting Reinforcements

The release also includes several important supporting improvements that strengthen the three main claims without replacing them.

Layered architecture review

Architecture analysis can now opt into a layered preset rather than stopping at import cycles alone.

A simplified configuration looks like this:

architecture:
  enabled: true
  preset: layered

The built-in intent is narrow by design:

api -> domain allowed
domain -> data forbidden
domain -> service forbidden
domain -> api forbidden

This is not enabled by default, and that is correct. Architecture review is valuable only if it avoids becoming a false-positive factory.

Canonical CLI

The public CLI is now much easier to hold in memory:

scan
review
pulse
sweep

That simplification matters because adoption dies when the interface surface grows faster than user confidence.

Selective Rust acceleration

Performance work also stayed disciplined. The project did not rewrite itself around native code. It kept Python as the product core and used Rust only for measured hot paths such as:

file walking
glob-heavy traversal

That is the right trade. Native code is a performance helper here, not a product identity.

Five Topics Worth A Deeper Follow-Up

The following five areas deserve separate technical notes because they are where the release’s architecture becomes most visible.

1. Mathematical Model Hardening

The scoring model did not need a louder formula. It needed a safer boundary.

That is why the important work happened around validation, metric guards, cross-language aggregation, attributed deficit output, and deterministic fallback above scale thresholds. The benefit is practical: fewer strange summaries, safer config changes, and score outputs that are easier to debug.

scan -> validated metrics -> attributed score -> project summary

The model now behaves less like an opaque detector and more like a measurement subsystem.

2. Cleanup Confidence Planning

“This might be dead code” is not enough guidance for real cleanup work.

v3.8.1 moves cleanup closer to a review plan by attaching confidence, action class, and evidence to cleanup-family findings. The key design choice is reuse: cleanup confidence draws from existing signals such as deficit, churn, coverage, and local evidence instead of inventing a second truth system.

sweep dead-code -> ranked issue -> action class -> evidence

That makes cleanup safer for humans and easier for agents to consume.

3. Manifest-Aware Dependency Hygiene

Dependency debt is often project-level, not file-local.

By comparing declared dependencies, imported dependencies, and normalized top-level mappings across pyproject.toml and package.json, the tool can now surface manifest-level problems such as unused declared packages or missing declarations.

manifest -> imports -> used / unused / missing -> cleanup output

That turns unused-deps from a file hint into a repository hygiene signal.

4. Layered Architecture Review

Cycle detection is useful, but many architecture failures appear before cycles do.

The layered architecture preset gives teams an opt-in way to express allowed and forbidden import directions, with evidence attached to the violation. The important part is restraint: this is not forced on every repository.

boundary-violations -> cycles + optional layered rule review

That keeps architecture review useful without turning it into noisy certainty.

5. Governance Verification Gate

Measurement and enforcement should not collapse into the same layer.

The governance gate creates a deterministic artifact, verifies it separately, and fails closed when policy or integrity checks break. That makes CI behavior more explicit and audit-friendly.

scan -> governance artifact -> verify-governance -> pass / fail

This is one of the strongest separations in the system: measurement, artifact generation, and enforcement each have their own boundary.

Why This Category Will Keep Growing

We are still early.

Most teams are only beginning to feel what large-scale AI-assisted development actually does to a repository over time. At first it feels like acceleration. Then it starts to feel like churn, duplication, abandoned logic, inflated structure, and uncertainty about what is still safe to touch.

That is why interest in slop will keep rising.

The more code agents can generate, the more valuable tools become that help humans decide what should never have remained in the codebase in the first place.

As agent-driven code development becomes more mainstream, the need for systems like this will likely accelerate:

measure structural trust
prioritize cleanup
separate evidence from policy
make deletion safer
make governance explicit

AI-SLOP-DETECTOR is being built gradually in that direction.

Not as a one-shot idea.
Not as a trend-chasing wrapper.
Not as a linter with a fashionable label.

But as a system shaped step by step around a simple reality:

if AI makes code generation cheap, then structural review, cleanup discipline, and governance become more valuable than ever.

That is the craft mindset behind this project:

refine the instrument
tighten the workflow
separate the layers
improve the trust surface one release at a time

That is the craft mindset behind this project:

refine the instrument
tighten the workflow
separate the layers
improve the trust surface one release at a time

Repository: https://github.com/flamehaven01/AI-SLOP-Detector

Sibling Rivalry? How to Make Kestra Tasks Talk to Each Other

Thu, 23 Apr 2026 15:49:01 +0000

I'm putting together a video on sibling tasks in Kestra and thought I would build this idea out loud with you in a blog first.

Let's jump in!

What are sibling tasks?

Sibling tasks are tasks that have the same parent task. For the rest of this blog, we'll refer to sibling tasks within the context of a dynamic or looping construct.

So in this case, we can be more specific and say sibling tasks are the tasks defined within the tasks list of a loop. If we use ForEach as an example, we could have something that looks like this:

- id: my_loop
  type: io.kestra.plugin.core.flow.ForEach
  values: ["alpha", "beta"]
  tasks:
    - id: first_sibling
      type: io.kestra.plugin.core.debug.Return
      format: "Data for {{ taskrun.value }}"

    - id: second_sibling
      type: io.kestra.plugin.core.log.Log
      # Accessing the sibling's output for the current iteration
      message: "The first sibling said: {{ outputs.first_sibling[taskrun.value].value }}"

The ForEach, or my_loop, is the parent, with the siblings being first_sibling and second_sibling.

In this example you can see our log message contains info passed from first_sibling with the expression syntax. You will see this in the docs as "sibling task lookup". Pay attention to the differences between sequential and dynamic tasks, like looping.

Execution & `TaskRun` context

You may be familiar with the concept of context or scope and I think this is where things can start to get confusing.

A task run is a single execution of an individual task within a larger workflow execution. When you are within a ForEach's task list, you'll want to use taskrun.value to get the value associated with that run or iteration.

This might be a bit different to how you've done looping with programming languages where you are scoped within the brackets of the loop. You don't need to think about iterations, just the work happening within the loop.

Think of it like a "You Are Here" marker on a map. If you were hiking on a trail and came across a trail map with no marker to tell you where you are, it's not very helpful. You know you are on a trail and you could probably make a guess of where you are based on landmarks or time spent on the trail, but you could also be really wrong. And then get really lost.

Bringing it back to programming and workflows, using a key to indicate what run or iteration becomes hugely important when you are running tasks concurrently. This means the context needs a hint at what iteration you are interested in. I know I'm looking for data in the loop, but which run?

Outputs

Outputs are how you pass data between tasks or flows. Standard tasks usually reference outputs via {{ outputs.task_id.value }}. This gives you the value of a specific task's output.

In this case, we want to pass data between sibling tasks, which may look something like this {{ outputs.first_sibling[taskrun.value].value }}. This gives you the values of a specific run or iteration from the first_sibling task's output. This is very specific and helps prevent any conflict with concurrency or tasks firing in parallel.

We can't assume ForEach child tasks will run in parallel unless we set loop concurrency or use a parallel task.

I highly recommend reading our best practices page on this topic.

Outputs vs. execution & TaskRun context

But let's say we want to access data outside of the loop. We can do that too, modifying our example from above:

- id: my_loop
  type: io.kestra.plugin.core.flow.ForEach
  values: ["alpha", "beta"]
  tasks:
    - id: first_sibling
      type: io.kestra.plugin.core.debug.Return
      format: "Data for {{ taskrun.value }}"

    - id: second_sibling
      type: io.kestra.plugin.core.log.Log
      # Accessing the sibling's output for the current iteration
      message: "The first sibling said: {{ outputs.first_sibling[taskrun.value].value }}"

- id: outside
  type: io.kestra.plugin.core.log.Log
  # Accessing the data for the `alpha` run specifically
  message: "{{ outputs.first_sibling['alpha'].value }}"

This would give us the "alpha" iteration's output from the first_sibling task as a value.

Where it gets confusing

This tends to get confusing when you start using a mix of outputs and taskRun. When your output exists outside of the loop, you use the standard syntax. Inside the loop? You need to give Kestra the key (or value) associated with the particular iteration.

Additionally, your error messages can seem non-intuitive. You can will typically get an error where the value isn't found when you forget to use a key.

So let's look again at this example:

- id: outside
  type: io.kestra.plugin.core.log.Log
  message: "{{ outputs.first_sibling['alpha'].value }}" # correct

But if we ran this with the key, the value of the iteration we want to capture, we'll get an error.

- id: outside
  type: io.kestra.plugin.core.log.Log
  message: "{{ outputs.first_sibling.value }}" # will error

Unable to find `value` used in the expression `{{ outputs.first_sibling.value }}` at line 1

When to use double quotes

Double quotes around your expressions give a clear indicator that this value is a string. Without them, you may get that unintuitive error that the value in the expression cannot be found.

When I'm debugging my workflows, I usually try to make sure I have a key for my iteration and I've wrapped my expression in double quotes before I do any more extensive investigation. That usually solves it for me.

This should show up as a linting warning with a nice yellow squiggle, but it depends on the task properties and types you are working with.

When to use `ForEach` and `ForEachItem`

A bigger topic is the differences between ForEach and ForEachItem, which we have a great best practices page on.

The TL;DR is use ForEachItem when you want subflows and you are doing a lot of work on a lot of things.

Let me know if in the comments if you want a blog or video (or both!) on this topic.

Wrapping up

So that covers sibling tasks and outputs and expressions, oh my! Hopefully this adds a little more supplemental details to our docs on this topic.

As always, let me know if there is something you want me to explain in a little more detail! I'll get a video related to this topic out next week too.

Vulnerability Check & Triage Walkthrough

Tue, 14 Apr 2026 14:36:20 +0000

Use Kestra, Gemini, and Notion to automate a CVE (Common Vulnerabilities & Exposures) checker. Uses AI to get a little more assistance with triage.

Join me in this video walkthrough to see how you can build a similar solution and stay tuned until the end when I talk about pointers for what I would do to continue building or improve this!

Building a Self-Triaging CVE Checker with Gemini, Kestra, and Notion

Mon, 06 Apr 2026 14:41:55 +0000

I built a CVE checker for a nice enterprise-y use case, and of course, it's getting bigger and bigger as I go "ooooh, what if I add this?!" So this is me taking a break and telling you what I've done so far because this was the original stopping point.

The idea

I needed some kind of data to populate a Notion database (basically a table) so I could do something interesting with our Notion + Kestra plugins. Bonus points if I could sprinkle in some AI augmentation. Extra bonus points if I could make it a realistic enterprise example. Something that really resonates with the enterprise crowd.

And immediately I was like - CVEs!

The distraction

Side note, I spent far too long last week discovering that things may look like and act like Notion Pages, but a Notion Database is not a Notion Page. So if you give the API a Database id when it wants a Page id, it tells you it doesn't exist. Because a database is not a page. Hence, we have a Kestra plugin for Pages and a separate one for Databases now!

The Notion API makes you use UUIDs, but the value you need is presented in the URL if you are looking at Notion in a browser... but you need to turn that into a UUID. So my search history looks like this:

I also use Google Search to do calculations because I could not be bothered to open the calculator app when I'm already in a browser. Follow me for more tips on what Google Search can do.

What I built

I needed a list of CVEs, so I went out to CISA and found their Known Exploited Vulnerabilities Catalog. They make this available in a few formats, so I found it in JSON.

The objects are pretty clean and tidy and look something like this:

{
    "cveID": "CVE-2026-33017",
    "vendorProject": "Langflow",
    "product": "Langflow",
    "vulnerabilityName": "Langflow Code Injection Vulnerability",
    "dateAdded": "2026-03-25",
    "shortDescription": "Langflow contains a code injection vulnerability that could allow building public flows without requiring authentication.",
    "requiredAction": "Apply mitigations per vendor instructions, follow applicable BOD 22-01 guidance for cloud services, or discontinue use of the product if mitigations are unavailable.",
    "dueDate": "2026-04-08",
    "knownRansomwareCampaignUse": "Unknown",
    "notes": "https:\/\/github.com\/langflow-ai\/langflow\/security\/advisories\/GHSA-vwmf-pq79-vjvx ; https:\/\/nvd.nist.gov\/vuln\/detail\/CVE-2026-33017",
    "cwes": [
        "CWE-94",
        "CWE-95",
        "CWE-306"
    ]
},

CVEs are kind of notorious for being hard to understand. They can pop up randomly and the anxiety that comes with trying to decide if your codebase is impacted, plus how fast you need to mitigate them, can make things harder than necessary. So I wanted to augment this a bit and sprinkle in some AI to help. I want Gemini to help me set the priority and action plan and hopefully make it a little easier for a human to parse than the CVE itself.

I want to pass new vulnerabilities to AI because, as of writing this, the list is 1557 CVEs long and I want to be conscious of token use. I also think it's more realistic for my demo to have a smallish subset of CVEs to triage.

Once I have this, I want to send it to a Notion Database, where I can have a nice little visual table to assign a human reviewer and create a Notion Page on the specific CVE to capture any implementation details or other notes the human wants to provide for more context on how this applies (or doesn't apply) to us.

More on the design

I should start by saying, as always, I'm not looking to make highly performant, production-ready demos. There are times I want to do something less than ideal to show particular aspects or features of the product and workflow mechanics. The things I make should spark a conversation or ideation. Besides, you know your use case better than I do.

Now that I got the disclaimer out of the way, let's talk about the design of this demo.

Store individual CVE IDs in KV Store

I wanted to store the known CVE IDs in a way that was searchable within Kestra, and to do that I used the KV Store. The keys map to the CVE IDs and the values are the names. The CVE IDs will always be a specific format, but the names could be quite lengthy. However, I could see a case where I need to reference both in my demo.

This searchability within Kestra gives an admin a fast way to reference whether this is a known CVE in the system since the table in Notion will only show new known CVEs.

Iterate through the JSON

Since I have this running during off hours, I don't really care how long it takes. With 1500+ CVEs to iterate through, this takes about 20-30 minutes with the concurrency limit set to run some tasks in parallel (5). Without setting the concurrency limit and just letting this default to running everything sequentially, it takes over an hour. Again, running off hours, I could easily tolerate this.

What's next

I'm always like HOW DO I MAKE THIS EVEN BIGGER. What more can I pack into this demo?

Could I just iterate over the top of the JSON?

Rethinking how I iterate over the JSON. CVEs don't get reported every day, and sometimes multiple get reported in a single day. I could probably be smarter with the iteration and only "read" until I hit a known CVE in my system and then stop since CVEs are added to the top of the JSON response.

However, if I wanted to build a really robust example and look for any edits or updates to the CVE information (like whether there is a new known ransomware campaign) I would still need to iterate through all of them.

This assumes that the behavior I'm seeing, where the CVEs are added to the top of the JSON, is the typical practice. Since I've only been working with this list for ~4 days, this seems typical.

How would you approach this?

Pre-populate Notion pages with more CVE info

I want to pre-populate the page with more info from the CVE. When I add a new item to the database, I get the page id returned. I could then take this page id and send over some content with the rest of the info in the JSON. In the execution outputs, I actually have all that info returned in the Database CreateItem task, so this would be quite trivial. They even give me the page ID as a UUID!!!!

Oops, found a bug

I wanted to add a checkbox about whether it should be mitigated now. To me, this is different than priority, but more of an urgency indicator. There's a bug with the Notion Database plugin where I couldn't pass in a boolean, so I removed the checkbox for now.

Wrapping up

If you want to view or use this example you can find it over on GitHub. I do not recommend running it the first time with the AI and Notion tasks enabled because you'll get 1557+ CVEs run through Gemini and added to your Notion database. Comment those out for the first run.

In fact, as I was building this demo the last ~4 days, the CVEs trickled in at a near perfect rate for me to see 1-3 pop into the table, but often I would have to delete a KV item manually to ensure I could get something to populate in my table.

If you use it as inspiration, let me know what you are building, or what you want to build! Keen eyes will notice I used Kestra EE, but you could definitely build this with Kestra OSS too with a few tweaks for things like secret management.

Anatomy of a Kestra Flow: How It All Fits Together

Thu, 19 Mar 2026 15:48:35 +0000

Join Developer Advocate Amara Graham as she walks through 4 example flows of increasing complexity to show you different workflow components, required properties, and tactics for making your flows easier to read and maintain.

Try Kestra for free: https://go.kestra.io/yt/try-kestra

All flows in this video, except the hello world boilerplate, are available as blueprints:
log_off_flow (available in two options: Notion or Confluence)
With Notion
With Confluence
airbyte-sync-parallel-with-dbt
argocd-single-tenant-wave-rollout

Workshopping my "Anatomy of a Kestra Flow" idea

Tue, 10 Mar 2026 20:53:44 +0000

I pulled together a quick video where I step through 4 different workflows and kind of talk through some ideas I had for more of a polished video. Let me know what you'd like me to focus on or where I should go into more details!

Like these "working out loud videos"? Let me know that too! I'm happy to share more rough drafts in my quest to learn in public.

This was originally posted on dev.to via https://dev.to/missamarakay/workshopping-my-anatomy-of-a-kestra-flow-video-idea-d8h.

What even is orchestration?

Thu, 19 Feb 2026 20:41:09 +0000

I accidentally ended up in the process automation and orchestration space when I started my career, and somehow even more accidentally I'm still there. As Taylor Swift says, "help, I'm still at the restaurant."

Being in the enterprise software space this long, I feel like the pendulum has swung back and forth between "buy a full suite platform, it has everything you need" and "avoid vendor lock-in" and something in between. AI has certainly left it's mark, but hasn't changed things all that dramatically.

You'll find people and companies saying you need a specialized purpose-built platform with a very specific set of use cases or personas or one that's agnostic and fits any and all needs.

It's no different in the process automation and orchestration space.

All of this to say, we still have the same problem - this separation in ownership and responsibilities from the thing we want to improve and how it's actually going to be improved. You often here this positioned as "the business" and "the development team". "The business" gets pitched as this non-technical group of diagram drawing, process optimizing suits while "the development team" adds the code and system integrations to make the diagram actually work, but doesn't own the process.

I still look back on my early career days and remember our business partner asking if she could just give me a Visio diagram and could I turn that into BPMN for her because the standards were too technical. BPMN... as in the standards that were supposed to be the literal language that filled this "gap" between "the business" and "the development team"... was too technical. Interesting.

I have this hypothesis that people in tech generally understand process automation and why it's beneficial, but only certain areas and roles within tech seem to really resonate with the term "orchestration". So maybe let's talk about that a bit and give you a few examples of where orchestration really shines. Then you can tell me your definition.

Ok, so what is orchestration?

You would think it's overdone, but the analogy of a conductor with an orchestra really fits here. You have a bunch of different instruments kind of doing their own thing, but together, with the help of a conductor, making a beautiful coherent piece of music happen. They get clues on when to speed up, slow down, or when to play with more or less intensity.

But I can see how that doesn't translate super well to tech.

Let's get some help from the internets.

Orchestration is the coordinated execution of multiple IT automation tasks or processes. Orchestration is usually applied across multiple computer systems, applications, and services to ensure that deployment, configuration management, and other processes are performed in the proper sequence.

Via RedHat

Orchestration is the coordination and management of multiple computer systems, applications and/or services, stringing together multiple tasks in order to execute a larger workflow or process. More specifically, orchestration is the coordinated execution of multiple IT automation tasks or processes across multiple computer systems, applications and services. These processes can consist of multiple tasks that are automated and can involve multiple systems.

Via Databricks

Orchestration is the process of coordinating distributed software components and systems so that they execute seamlessly as an automated, repeatable process.

Via Orkes

These definitions read a lot like the DevOps definitions - multiple systems, coordination, working together with automation, etc.

Basically, anytime you want to do something complex and chain together a sequence of tasks or coordinate and manage multiple systems, applications, or services either ad-hoc, scheduled, or when something happens somewhere you probably want to do it in a clear and reusable way with orchestration. Got it? So clear!

You'll see orchestration and automation together quite often, but it's typically positioned around the involvement of humans where automation is helping humans, without intervention, complete a single task. Orchestration tends to be more complex, but may involve humans (human-in-the-loop). To what extent humans participate depends.

I think I get it, but I need examples...

Let's try to make this a little more tangible.

Data Orchestration

You have data everywhere, in multiple disparate systems, and now you want to do something with it. Very everything, everywhere, all at once. This is where you see data pipelines, ETL, etc. come into play. You don't necessarily want to merge all the data together into one big database, but you do want to coordinate across the systems to, say, use the data to make informed decisions.

Business Orchestration

This tends to be where process automation and orchestration live in the traditional IT, HR, and finance workflows. My favorite example in this space is a two-step approval process, because it involved a human-in-the-loop aspect (maybe even two!), but many people have seen this at work or in their personal life.

If you know what "signature authority" is you've definitely been a part of a process like this, and the larger the organization, the more systems might be involved to make decisions.

You may encounter a set of rules that fast track you through the process (like my "signature authority" was once $100, which was basically desk trinkets) and anything more than that was escalated to my manager until his "signature authority" limit was hit and then it escalated to his manager. So this system needs to know the org chart, the individuals' "signature authority", the price of the items to be purchased, etc. All of that info is definitely in different databases, if not completely different systems.

AI Orchestration

This is relatively new and gets us into murky territory as well. Agent orchestration, multi-agent systems (MAS), AI pipelines can all fall into this bucket of AI orchestration. MAS for me is really the foundation for where we are at now with AI agents and potentially having them do coordinated work together.

The agents need data, then with that data they do something with other agents, and something complex happens.

I'm intentionally being a bit handwavy here because I don't have a great real world example of this yet, just a lot of marketing blogs around specialized agents working together to complete a common goal.

But when do you need an orchestrator?

It depends, of course.

Some organizations will start building some stitched together, homegrown solution and ultimately hit a point where there is a maintenance or scale issue. Others will realize they want to do something beyond CRON and scheduled jobs, something more real-time and event-based where they need listeners or webhooks.

Others still will realize they need to do a mix of scheduled, event-based, and manual executions with responsibilities spanning across technical and non-technical roles, and this is usually when they start investigating platforms to handle some of this.

So, how do you define orchestration?

Hopefully, I've given you a bit to think about and start to formulate your own opinion on orchestration.

What's your definition of orchestration? Are you doing orchestration within your organization? And how did you evaluate your options?

Sources & further reading

My First Flow with Kestra.io

Fri, 06 Feb 2026 13:00:00 +0000

As I'm learning more about Kestra.io, the community, and the possible use cases, I wanted to build a small PoC (proof of concept) that resonated with me and leveraged a fair amount of the platform aspects so I could get some hands on learning beyond the existing tutorials and examples (which are great! Give them a try!).

After talking with a coworker, I loved his daily reminder to log off scheduled on his calendar. This kind of daily ritual is really great for wrapping up your day and leaving work at work. Or at least trying to.

I told him I was going to 100% steal his idea.

Let me walk you through what I'm doing and learning as I go. This won't be a tutorial, but you can see how I learn and explore a new platform, following along with links back to the docs if you want to learn even more.

Requirements of the PoC

I wanted to make sure this PoC covered multiple aspects of the platform, even if it might be a little trivial at times. I wanted to see the dashboards populate with some data, use a few plugins, and start to see the difference between the OSS Edition you can access for free and the paid experience with the Kestra Enterprise Edition.

I needed to interact with the following during my daily or weekly shutdown:

Scheduler/chron - what? You think I would remember to do this daily?
Slack - our main communication tool and where my weekly recap ultimately needed to land, but also where I'll get the reminder
GitHub - no surprise here, where the bugs, feature requests, issues, and PRs live for the source code and docs
Notion - Throw this recap into my "Weekly recaps" so it doesn't get lost on Slack
Google Calendar - Read my calendar and remind me who I talked to today or this week

All of these looked like plugins that should reasonably work well for my PoC. Excellent!

For my first iteration, I won't make this too terribly smart and it will prompt and grab the same info everyday, just for that day. Maybe v2 will do something more comprehensive on Friday when I actually write my weekly recap.

After a quick search through the Blueprints, I didn't find anything specific that I wanted to build off of, so I ended up starting from scratch. I usually recommend building from or extending tutorials and existing examples.

I should also mention I'm building this flow with the flow code editor, directly editing the YAML.

What's a plugin?

Plugins are the essential building blocks for tasks and triggers in your workflow in Kestra. This might be a subtle shift from some platforms where the plugins are extensions or integrations, which they are in Kestra too, but they also include core functionality. You'll probably end up using several plugins in your flow, and many more if you are doing something non-trivial.

See if you can spot the plugins I use in the YAML snippets below. You'll see a mix of 3rd party integrations and core functionality.

Kestra UI

Learning new tools always requires spending a little time mapping your existing knowledge to the UI and terms.

One of the things that I really struggled with early on was the purple, primary action button in the top right corner of the UI changes depending on what screen I'm on. So it could be used to create a flow, execute a flow, create a user (in Kestra Enterprise Edition), etc.

Leave me a comment and let me know how you feel about this UI design choice. Is it intuitive for you? Do you want a more descriptive button name?

Triggers

You probably want to do something when something happens, whether that's a moment in time or based on an event like a form being submitted or new data arriving. You need a trigger for that. For my PoC, I want this to run every weekday around 4pm, when I'm thinking about wrapping up for the day.

triggers:
  - id: daily_shutdown
    type: io.kestra.plugin.core.trigger.Schedule
    #UTC Austin @ 4pm (could add timezone), except weekends
    cron: 0 22 * * 1-5

I like these at the top of the YAML because they show me exactly when this flow happens.

Tasks

Flows require at least one task. You simply cannot save a flow without a task. This makes sense because why would you have a flow that does nothing.

I'll have several tasks in my flow, but I want to make sure I see a reminder or prompt in Slack. That will look something like this with the Slack plugin:

id: send_reminder_message_to_slack
    type: io.kestra.plugin.notifications.slack.SlackIncomingWebhook
    url: "{{ secret('SLACK_WEBHOOK') }}"
    payload: |
      {
        "text": "Time to shutdown"
      }

I'll need to revisit this to add something more interesting to the payload (like info from other tasks), but sending a Slack message is as easy as getting the tokens and secrets configured.

Eventually, it will look like this:

id: send_meetings_to_slack
      type: io.kestra.plugin.notifications.slack.SlackIncomingWebhook
      url: "{{ secret('SLACK_WEBHOOK') }}"
      payload: |
        {
          "text": "Here are the meetings you went to today: {{ outputs.get_calendar_events.events }} "
        }

But we'll talk more about outputs a bit later.

Logging

I ended up doing a lot of logging tasks between the tasks that used plugins, mostly to verify what was coming back in the response and if I wanted to do anything else.

- id: get_cal_list_log
    type: io.kestra.plugin.core.log.Log
    message: "{{ outputs.get_calendar_events }}"

I'm still having some trouble getting the Google Calendar plugin to send more than an empty array back, so for now I'm logging the whole object I get back to see if I get any clues.

Flowable tasks

I threw in a flowable task because depending on how you classify a meeting, I don't have meetings everyday. I do have a blocker for lunch everyday, which is technically a meeting...

- id: if
    type: io.kestra.plugin.core.flow.If
    condition: " {{ outputs.get_calendar_events.events  == [] }} "
    then:
    - id: send_no_meetings_to_slack
      type: io.kestra.plugin.notifications.slack.SlackIncomingWebhook
      url: "{{ secret('SLACK_WEBHOOK') }}"
      payload: |
        {
          "text": "Hooray! No meetings today."
        }
    else:
    - id: send_meetings_to_slack
      type: io.kestra.plugin.notifications.slack.SlackIncomingWebhook
      url: "{{ secret('SLACK_WEBHOOK') }}"
      payload: |
        {
          "text": "Here are the meetings you went to today: {{ outputs.get_calendar_events.events }} "
        }

I really like the human readable way this, well, reads. If, then, else shows me what the condition is and what's going to happen for the two branches.

I know some platforms allow you to define a default path for flows, but I didn't see that here, which I actually really like. Introducing a default path feels confusing when you should rely on the evaluation of the condition.

As I mentioned above this is currently always getting [] back from the Google Calendar plugin, so apparently I never have meetings, but when it works I'll have that taken care of with this flowable task.

Outputs

I added an output that was trivial because I was most likely going to send the summary of the work I did to Slack in the message payload and wasn't sure if there would be any difference if I did or didn't have an output.

outputs:
  - id: sent_bool
    type: BOOLEAN
    value: "true"

In the execution outputs, I wanted to see something I added and where it would show up in the UI. Again, trivial, because in this iteration I don't anticipate this flow making data available for a subsequent flow.

I did use outputs across the various tasks too, so I could use the data from one task in the following task.

Revisions

Don't do what I did as a lazy developer and put my secrets right into my flow. They stay in your revision history. Plain text. Oops.

Secret handling in the Enterprise Edition is too easy to not use, so don't put your secrets plain text in your flow. Keep your secrets secret. Then use an expression like below:

{{ secret('SLACK_WEBHOOK') }}

Revisions become really powerful as you are making changes to your flow, particularly while you are building and testing because sometimes a change doesn't work like you want, and through revisions you can see exactly what changes were made.

Where I'm at

I love that I can export an image of my topology directly in Kestra.

So for now I don't have a "working" increment that I'm happy with. While it is firing every day, I still need to dig into why Google Calendar thinks I have no meetings... when I definitely have meetings. I'm currently playing around with public/private event visibility to see if that changes anything. More on that next week I'm sure when I also add the Notion and GitHub plugins.

Have you built something with Kestra? Link me to your repo in a comment below.

Contributing to Kestra - Where to start and pointers to get there

Mon, 02 Feb 2026 19:05:31 +0000

I recently did a webinar where I talked with two Kestra contributors about their contribution experience. While our discussion was mostly centered around plugins, this reminded me we have multiple ways to contribute to Kestra and I figured I should cover them. While I know there is a big push to contribute during Hacktoberfest, contributions are accepted all year round!

Kestra has several areas or opportunities for contributions, and depending on your expertise, you may find some more interesting than others. We have a general contribution guide that covers the code base and documentation.

Where to start?

Both contributors mentioned started with technology they were already familiar with and looking for issues labeled good first issue. This is such a great strategy because the less you have to learn, the quicker you can get to doing!

Good first issue, at least at the time of writing this post, had a mix of front end, back end, and plugin issues. You may also see some issues for our docs, although most of those tend to be in the docs repo.

Docs

Having fresh eyes on a product and the docs gives you a really great perspective to review for intuitive design, clarity, and overall user experience. As you are reading and using the Kestra docs you may have questions or improvements that you notice. These make great opportunities for creating an issue (particularly if you need to clarify your understanding). If you have questions about documentation, it's entirely likely that others do as well.

We don't often label issues in the docs repo for good first issue but there are a few (at least at the time of writing this).

Plugins

Plugins are the foundation of tasks in Kestra flows and offer integrations outside of Kestra itself. Kestra has an extensive plugin library, but depending on the plugin, it may not offer complete cover of the API. Sometimes this is a bit of a design choice, other times it's simply because there was no use case for that particular endpoint of functionality. Extending the plugin is a great place to contribute.

If you are looking for ways to contribute to plugins, each plugin has it's own repo. You can look for issues there. Some plugin issues are also in the main Kestra repo.

There is also a dedicated plugin developer guide to help you understand the overall plugin landscape.

Blueprints

Seeing things in action with more of an end-to-end example is really helpful in truly understanding how something works. Blueprints combine multiple plugins to accomplish a goal and make it easy to get a flow started.

Find a plugin with no blueprint? This is a great opportunity to create a blueprint yourself. Think of a real world example. Bonus points if you use it when you are done.

Where will you make your first contribution to Kestra?

Photo by Taylor Burnfield on Unsplash

DevLog 20250807: Microservice for Cloud Scheduling (and Running)

Fri, 08 Aug 2025 04:22:53 +0000

Motivation

When working with routine tasks, it's convenient to have some form of automatic scheduling. Windows has Task Scheduler, Linux has cron, and in AWS, you can use Lambda with EventBridge.

Wouldn't it be nice if we could periodically pull data from the web, do some light processing, and then dump the results into a database - maybe update a website, trigger a CI/CD process, or send a few emails?

I haven't used it, but I imagine that's what Zapier is designed for. Azure/GitHub Actions are certainly handy for CI/CD. But what if we just want to quickly prototype something, ship it to a server, and forget about it?

That's the vision, anyway.

The First Attempts

When I first started building services for cloud computing, I combined both "trigger a run" and "schedule repeated tasks" into a single service. That sort of worked - but it didn't feel elegant. Something was off.

Even now, after deciding to completely separate the "runner" and "scheduler" into two distinct microservices, I can't fully articulate why this approach feels better. It just does. Of course, this means maintaining three or four separate programs now (runner, runner service, scheduler, scheduler service) - but each one is responsible for a single task, and that somehow feels more reassuring.

Separation of Concerns & the Single Responsibility Principle

I asked ChatGPT for a rationale that aligned with my intuition, and here's what it gave me:

What you're discovering is a classic case of separation of concerns (and in the microservice world, the "scheduler-worker" or "cron-vs-runner" pattern), underpinned by the Single Responsibility Principle. Here's why splitting "who decides when" from "what actually does the work" just feels better.

1. Single Responsibility & Cognitive Load

Scheduler service - its sole job is: "At 8 AM on Tuesdays, kick off job X."
Runner service - its sole job is: "When told to run X, do the fetch/process/dump."

By assigning each service a clear, focused purpose, you reduce logic complexity in any single codebase. You don't need to sift through your fetch logic to understand date calculations, and you don't need to worry about HTTP clients inside your scheduler.

Feels better because each code path is narrow, easy to reason about, and small enough to hold entirely in your head.

2. Loose Coupling & Replaceability

When the scheduler and runner communicate through a simple interface (e.g., message queue, webhook, or HTTP call), either can be swapped out independently:

Want to switch from cron-style fixed schedules to GitHub webhook events?
Need to rewrite your worker in another language for better library support?

You only have to reimplement one microservice - not the whole system.

Feels better because the impact of change is localized.

3. Independent Scaling & Reliability

Scheduling frequency and execution workload rarely match 1:1.

Maybe you schedule jobs every minute, but each run only takes a few seconds.
Or you only need one scheduler, but dozens of parallel workers to clear a backlog.

Separating the two allows for independent sizing, deployment, and monitoring.

Feels better because you avoid resource contention (e.g., a busy worker delaying the next schedule) and can autoscale each component based on its own metrics.

4. Clear Boundaries for Observability & Error Handling

Scheduler logs should only show: "Job X was triggered at time T."
Runner logs should only show: "Processing of job X succeeded/failed."

This allows for more targeted alerting and diagnostics:

Alert if a scheduled trigger never reaches the runner.
Alert if the runner fails more than N times, regardless of the schedule.

Feels better because root cause analysis is straightforward - you know where to look first.

5. Pattern Analogues & Ecosystem Support

This approach mirrors patterns built into major platforms:

AWS CloudWatch Events (scheduler) → Lambda (worker)
Kubernetes CronJob (scheduler) → Job pods (workers)
Celery Beat (scheduler) → Celery workers (task executors)

All of them separate the "when" from the "what," and you're starting to feel the same advantages they offer at scale.

In Summary

You're gravitating toward a Scheduler–Worker (or "Cron-as-a-Service" + "Stateless Runner") pattern because it:

Reduces cognitive load by narrowing each service's scope
Decouples timing logic from business logic
Enables independent scaling and more precise reliability controls
Improves testability (you can mock the scheduler in runner tests, and vice versa)
Aligns with proven cloud-native and messaging patterns

That "reassuring" feeling is the comfort of a clean, modular architecture - you can see exactly what does what, and update or extend each part without unraveling the rest.

The Analogy

Here is the way I understand it: a rough analogy might be batch-processing vs programming - when chaining multiple operations, it's better to use shell scripting than to rely on spawning subprocesses directly in your source code.

Coder Legion - Recent posts tagged orchestration

Introducing AIWorkHub: a repository-native control plane for AI coding agents

The problem is coordination, not another chat box

One isolated workspace per repository

A task lifecycle with a real review boundary

Source intelligence instead of repeated tree scans

Durable context has more than one job

Multi-model routing without copying credentials

Safety is part of the architecture

The dashboard

Install it

What comes next

AI-SLOP-DETECTOR v3.8.1: When Code Generation Gets Cheap, Structural Trust Gets Expensive

Why This Release Matters Now

Changelog Evidence Since v3.6.0

Claim 1: The Scoring Path Became Safer

What changed

Why it matters

Claim 2: Cleanup Became More Actionable

Cleanup confidence planning

Manifest-aware dependency hygiene

Why it matters

Claim 3: Governance Became Harder To Bypass

What changed

Why it matters

Supporting Reinforcements

Layered architecture review

Canonical CLI

Selective Rust acceleration

Five Topics Worth A Deeper Follow-Up

1. Mathematical Model Hardening

2. Cleanup Confidence Planning

3. Manifest-Aware Dependency Hygiene

4. Layered Architecture Review

5. Governance Verification Gate

Why This Category Will Keep Growing

Sibling Rivalry? How to Make Kestra Tasks Talk to Each Other

What are sibling tasks?

Execution & TaskRun context

Outputs

Outputs vs. execution & TaskRun context

Where it gets confusing

When to use double quotes

When to use ForEach and ForEachItem

Wrapping up

Vulnerability Check & Triage Walkthrough

Building a Self-Triaging CVE Checker with Gemini, Kestra, and Notion

The idea

The distraction

What I built

More on the design

Store individual CVE IDs in KV Store

Iterate through the JSON

What's next

Could I just iterate over the top of the JSON?

Pre-populate Notion pages with more CVE info

Oops, found a bug

Wrapping up

Anatomy of a Kestra Flow: How It All Fits Together

Workshopping my "Anatomy of a Kestra Flow" idea

What even is orchestration?

Ok, so what is orchestration?

I think I get it, but I need examples...

Data Orchestration

Business Orchestration

AI Orchestration

But when do you need an orchestrator?

So, how do you define orchestration?

Sources & further reading

My First Flow with Kestra.io

Requirements of the PoC

What's a plugin?

Kestra UI

Triggers

Tasks

Logging

Flowable tasks

Outputs

Revisions

Where I'm at

Execution & `TaskRun` context

When to use `ForEach` and `ForEachItem`