# Automations evolution

**URL:** https://community.tuist.dev/t/automations-evolution/964
**Category:** RFCs
**Created:** [April 7, 2026, 6:43pm UTC](https://community.tuist.dev/t/automations-evolution/964 "2026-04-07T18:43:49Z")
**Posts on this page:** 1
**Showing post:** 4

<div class="post-metadata">

### Author: ![pepicrft](https://community.tuist.dev/user_avatar/community.tuist.dev/pepicrft/32/5_2.png) [@pepicrft](https://community.tuist.dev/u/pepicrft)
#### Post date: [April 8, 2026, 5:53pm UTC](https://community.tuist.dev/t/automations-evolution/964/4 "2026-04-08T17:53:55Z")

</div>

Thanks for putting this together 🙏

I’m on board with the solution, phasing, and layering. Once we iterate to something more programmable, it’ll feel like an _ejection_ to the user, but all we’ll end up doing is allowing them to drill down a layer and get to the engine primitives that make this possible.

Another example you might want to include as a reference is [Ona](https://ona.com/docs/ona/automations/overview) and their automations, which I believe embrace a `.yaml` format:

```auto
tasks:
  install:
    name: Install dependencies
    command: npm ci
    triggeredBy:
      - postDevcontainerStart

```

I’d keep an eye on how this space (agentic automation) evolves, because I believe we’ll see some patterns emerging around how to codify automation that includes non-deterministic agentic steps. I also think this primitive has the potential to be _shareable_ by the community as our platform has more capabilities (e.g. we expose more data and signals)

---

_[View the full topic](https://community.tuist.dev/t/automations-evolution/964)._