19:49Nate Herk | AI Automation · Demo
I Turned GPT-6 Astra Into the Ultimate AI Second Brain
A creator maps his entire business into Codex using a four-layer framework, then scores the result like a KPI.
September 7thThe argument in one line.
Codex can plan and build almost any automation, but the smart move is to keep genuinely predictable automations off the Codex subscription entirely by hosting the generated code on Trigger.dev, and reserve the costlier full agentic Codex SDK loop for the rare routine whose step count truly can't be predetermined.
Read if. Skip if.
READ IF YOU ARE…
- You're already using Codex or a similar coding agent to build personal or business automations and are worried about burning your weekly usage limit.
- You run recurring AI routines (morning briefs, webhook notifications, research loops) and want a cheaper, more reliable place to host them than a chat thread.
- You want a simple mental model for deciding when an automation needs a full autonomous agent versus a fixed step-by-step script.
SKIP IF…
- You don't use Codex, Trigger.dev, or a comparable agent-plus-hosting stack, since the walkthrough is tool-specific.
- You're looking for no-code automation tools like Zapier or Make; this is a code-first, developer-adjacent workflow.
The full version, fast.
Nate Herk shows how to stop burning Codex's weekly usage limit on routine automations by having Codex build the code, then hosting it on Trigger.dev instead of running it inside a chat thread. He splits automations into three types: scheduled (a morning calendar brief), webhook-triggered (a form submission that drafts a ClickUp outreach message), and Codex-SDK-powered agentic loops (a trading research routine that can't predict its own step count in advance). The deciding factor is determinism: if an automation's steps happen in the same order every time, it should be a cheap deterministic script with AI only at the reasoning steps, not a full agentic loop. Codex plans the build, tests it locally, connects to GitHub and Trigger.dev via CLI, deploys, and debugs a live failure (a disabled flag, then a duplicate-message guard) before Nate proves delivery works end to end.
Free for members
Chat with this breakdown — free.
Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.
Create a free account →Where the time goes.
00:00 – 01:36
01 · Why Host Outside Codex
Opens with the core problem: scheduled and event-triggered tasks run inside a Codex chat thread still burn the same weekly usage limit as any conversation. The fix is to have Codex build the automation, then host the resulting code somewhere else. Needs: a Codex subscription, a Trigger.dev account, and a GitHub account.
01:36 – 02:04
02 · Three Automation Types
Names the three patterns covered in the video: a scheduled automation, a webhook automation, and a Codex SDK automation.
02:04 – 04:44
03 · Planning A Morning Brief
Brainstorms a 6am morning-brief automation with Astra inside Codex: read Google Calendar, decide if research is needed, draft a short brief, and DM it via ClickUp. Codex asks clarifying questions about delivery channel, timing, and research budget before building.
04:44 – 07:53
04 · Deterministic Vs Agentic
Draws out the difference between a deterministic automation (fixed step order, AI only where judgment is needed) and a non-deterministic/agentic one. Argues roughly 90% of business and personal automations are deterministic, so running them as a full agentic Codex loop is wasteful. Includes a mid-chapter sponsor read for Hyperagent.
07:53 – 11:54
05 · Build And Validate Locally
Codex builds the morning-brief automation with test-driven development, sends real test DMs, and reports the run cost (about 1.33 cents) before anything moves to a host. Explains keeping API keys in one .env file rather than Codex's plugin system, so they can be copied straight into Trigger.dev later.
11:54 – 16:45
06 · Deploy To Trigger.dev
Creates a Trigger.dev account and project, connects GitHub and Trigger.dev to Codex via CLI OAuth, and has Codex create a private GitHub repo plus its own Trigger.dev project to host the code.
16:45 – 20:13
07 · Test Hosted Delivery
A first hosted test run produces no ClickUp message because Codex had left the automation's enabled flag set to false. After fixing it, a second run appears to do nothing again, but it's actually the automation correctly skipping a duplicate send; overriding that guard proves delivery works end to end.
20:13 – 25:54
08 · Webhook Automations
Builds a simple local form (name, email, team size, need) whose submission triggers a hosted Trigger.dev task that drafts an AI outreach recommendation and DMs it to ClickUp. Notes the notification step needs no AI at all; only the drafting step does. Flags edge cases (spam, field validation) worth stress-testing with sub-agents, then plugs a free "First Client SOP" lead magnet.
25:54 – 29:16
09 · Codex SDK Automations
Introduces the third pattern for tasks whose step count is genuinely unpredictable, using his own live trading-research routine as the example. Recommends staying on a normal Codex scheduled task unless the routine must run programmatically at scale.
29:16 – 32:07
10 · Moving An Agentic Routine
Migrates his real "Astra trading challenge" thread into a Codex-SDK-hosted Trigger.dev task: it wakes on a schedule, checks Alpaca, runs research, reads its own past logs, and emails a recommendation to a separate Grok-based bot that places the actual trade.
32:07 – 35:02
11 · Testing The SDK Workflow
Codex builds four supporting tasks around the one recurring worker (preflight check, install plan, proof/dry-run, and the live check), runs 44 tests, and Nate confirms it's working by watching real research and recommendation messages land in the same ClickUp thread the manual version used.
35:02 – 35:25
12 · Final Takeaways
Closes on the cost rule (subscription cheaper than API credits per run) and the standing decision rule: script the predictable parts, and only reach for the full agentic SDK loop when a task's steps truly can't be predetermined.
Lines worth screenshotting.
- Running a scheduled or event-triggered automation inside a Codex chat thread burns the same weekly usage limit as any other conversation, even if a human never looks at it.
- Moving a Codex-built automation to a host like Trigger.dev keeps the subscription free for actual work, since Trigger.dev runs the generated code independently.
- About 90% of practical business and productivity automations are fully deterministic: a fixed sequence of steps where AI only fills the reasoning gaps, like research or drafting a message.
- A deterministic automation only needs AI at the specific steps where the outcome is genuinely unpredictable, such as summarizing new information or writing a one-off message.
- An agent left in charge of a repeating routine can drift over time; one host reported his own DM-sending automation eventually started messaging the wrong channels after roughly a month of unsupervised runs.
- Hard-coding the destination (like a ClickUp channel and message ID) into the generated script removes the chance that an agent reinterprets a routine instruction differently on a later run.
- Keeping API keys in a single local .env file, instead of connecting accounts through Codex's plugin system, is what lets those credentials be copied straight into a new host like Trigger.dev.
- A single run of a working AI-assisted morning-brief automation, including the calendar read, research, and message draft, can cost under two cents.
- The Trigger.dev free tier can delay a 6am scheduled trigger by up to an hour, which matters if a routine needs to fire at an exact time.
- A webhook-triggered automation, such as a website form submission, only needs AI for the step that has to generate new content, like drafting an outreach message; the notification step itself can run on pure placeholders.
- The Codex SDK is worth reaching for only when a routine's number of steps is genuinely unknown in advance, such as a research loop that may need to re-check data multiple times before concluding.
- Paying to run an agent through API credits (the Codex SDK route) costs more per run than paying for the same reasoning through a flat subscription, so a routine should stay on the subscription unless it must run programmatically at scale.
- As of this build, mainstream model providers won't execute trades directly, so the automation emails its recommendation to a separate bot (built on Grok) that actually places the trade.
Determinism Decides When You Need An Agent
AGENT VS SCRIPT
Whether an automation should run as a fixed script or a full autonomous agent comes down to one question: is every step in it actually predictable in advance?
01Why Host Outside Codex
- Any scheduled or event-triggered task run inside a Codex chat thread counts against the same weekly usage limit as regular conversation, even when it runs unattended.
- The fix isn't avoiding Codex, it's splitting the job: use Codex to plan and write the automation, then host the resulting code somewhere outside the subscription.
- The three tools needed for this workflow are a Codex subscription, a Trigger.dev account, and a GitHub account.
02Three Automation Types
- Automations split into three buckets worth knowing before you build: scheduled (time-based), webhook (event-based), and Codex SDK (fully agentic).
- Picking the wrong bucket is the main way people overspend: using an agentic loop for a job that's actually predictable wastes both money and reliability.
03Planning A Morning Brief
- Before any code gets written, the planning step is a back-and-forth conversation with the agent to lock down exactly what should be checked, decided, and sent, and where.
- Being specific about delivery details up front, like which channel, which account sends it, and an acceptable cost ceiling per run, avoids rework once the automation is live.
- The agent can reuse context already sitting in an existing project (like a prior workflow) to understand intent faster.
04Deterministic Vs Agentic
- A deterministic automation runs the same numbered sequence of steps every time; only the specific steps that need judgment (research, drafting a message) are AI-driven.
- The rule of thumb: the more predictable an automation's steps are, the more wasteful it is to run it as a full agentic loop instead of a scripted flow.
- An unsupervised agent given open-ended judgment can drift over time; a routine like this reportedly started messaging the wrong channels after about a month of running as a full agent instead of a fixed script.
- Hard-coding the exact destination (channel ID, message format) into the generated code, instead of letting an agent reinterpret an instruction every run, is what keeps a deterministic automation behaving the same way indefinitely.
05Build And Validate Locally
- Keeping API keys in one local .env file, rather than connecting accounts through Codex's plugin system, is what lets those same credentials be copied straight into an external host later.
- Codex validates its own build with test-driven development before handing it off, including sending real test messages and checking what each run costs.
- A full working run (calendar read, AI research, AI-drafted message, delivery) can land under two cents, which is what makes a per-run cost ceiling a reasonable guardrail rather than a real constraint.
06Deploy To Trigger.dev
- Connecting Codex to GitHub and Trigger.dev via their CLIs lets Codex push code and configuration itself, rather than you copying files by hand.
- Routing code through a private GitHub repo, not just pushing straight to the host, gives version history and lets a teammate pick up and modify the automation later.
- The Trigger.dev free plan's scheduling window can delay a fixed-time trigger (like 6am) by up to an hour, which matters if exact timing is a requirement.
07Test Hosted Delivery
- A first hosted test run can fail silently for a boring reason, like an environment variable still set to disabled from the build step, so checking config values is the first debugging move, not a code rewrite.
- A second test appearing to 'do nothing' isn't automatically a bug: duplicate-prevention logic correctly skipped resending a message it had already delivered earlier that day.
- Verifying a hosted automation end-to-end means deliberately overriding safety checks like duplicate prevention at least once, so you've actually seen the real delivery path work, not just the skip path.
08Webhook Automations
- A webhook automation needs AI only at the step that has to generate new content, such as an outreach draft; the notification step itself can run on pure placeholders with no AI cost.
- Before launch, a webhook-triggered automation should be stress-tested for edge cases like spam submissions and malformed fields, which a swarm of sub-agents can probe faster than manual QA.
- The webhook pattern generalizes past forms: a new CRM record, a new inbox email, or any other event can be the trigger instead.
09Codex SDK Automations
- The signal that a routine needs the full Codex SDK, not a deterministic script, is that its own step count is unpredictable, like a research loop that might need to re-check data an unknown number of times.
- The default should stay a Codex scheduled task for routines you want to keep on your subscription; only move to the SDK when the routine must run programmatically at a scale your subscription can't cover.
- Increasing a routine's autonomy increases its risk, cost, complexity, and maintenance together, so the standing rule is to build the simplest version first and only climb the 'AI systems pyramid' when the simpler version genuinely can't do the job.
10Moving An Agentic Routine
- Migrating an existing agentic routine means describing that existing process to the agent so it can be reimplemented as a hosted SDK task rather than rebuilt from scratch.
- Because mainstream model providers won't execute trades directly, the automation's actual action is sending an email recommendation to a separate bot built to place the trade, keeping the AI's role limited to research and judgment.
11Testing The SDK Workflow
- A single agentic worker in production is often backed by several supporting tasks (a preflight connectivity check, an install/setup routine, and a dry-run proof task) that only the main scheduled task needs to keep running long-term.
- An automation correctly declining to act, like reporting 'early' because the market was already closed, is a sign it's respecting its own guardrails, not a failure to investigate.
- The real proof a hosted agentic automation works is watching its actual output land in the same channel a human-run version used, with the same research and recommendation quality.
12Final Takeaways
- Running an agent through pay-per-use API credits costs more per run than the same reasoning through a flat subscription, so keeping a routine on the subscription is the default, not the SDK.
- The deciding question for every new automation is still determinism first: script it deterministically with targeted AI steps unless the task genuinely can't be predetermined.
Terms worth knowing.
- Codex
- OpenAI's coding-agent product used throughout to plan, write, and test the automations; its composer shows a selectable model/persona labeled "GPT-6 Astra," which the host refers to conversationally as "Astra."
- Trigger.dev
- An open-source TypeScript platform for hosting and scheduling background jobs and AI workflows outside of a chat subscription, used here as the host for the generated automations.
- Deterministic automation
- A process that runs the same fixed sequence of steps every time, using AI only for the specific steps that need judgment or writing.
- Codex SDK automation
- A routine built as a full autonomous agent, rather than a fixed script, for cases where the number and order of steps can't be predicted in advance.
- Webhook automation
- An automation triggered by an external event, like a form submission or a new database record, rather than a fixed time schedule.
- .env file
- A local text file for storing API keys and secrets so they can be reused across tools instead of relying on per-tool plugin connections that don't transfer between platforms.
Things they pointed at.
12:30toolGitHub
29:52toolAlpaca
30:50toolGrok / Grokbot
03:20toolClickUp
Lines you could clip.
07:53
“The more deterministic your automation gets, the more of a waste it would be to use Codex to host that.”
08:20
“It started to just go rogue... it just randomly started to send to different DM channels.”
31:40
“Build the simplest solution possible and only move up the AI systems pyramid... when you truly need that functionality.”
34:50
“Paying for Astra via API credits is obviously more expensive than paying for Astra via subscription.”
Word for word.
Read-along
Don't just watch it. Burn it in.
See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.
metaphorstory
Codex lets you build automations right inside of it using scheduled tasks. However, because these scheduled tasks basically just send messages right into an actual chat thread, what that means is this eats at your actual weekly usage limit. So it doesn't really make sense to build a bunch of your personal and company automations inside of Codex.
A lot of the most useful automations can run somewhere completely independently of Codex, but we can use Codex to help us build them. So that's exactly what I'm gonna show you guys today. Even if you have no technical background at all, by the end of this video, you'll see how to build scheduled automations or ones that are triggered on some sort of event.
that live outside of Codex so they don't eat away at your subscription. So I don't wanna waste any time today. Let's just get straight into this one.
So like I said, when you have an automation running inside of Codex all the time, it's eating away at your subscription limit. So what I'm gonna show you guys today is how we actually build our automations with Codex. And then instead of actually hosting them there, we're going to host them in something called trigger .dev.
Because when we actually build the automation, what happens is we can actually just turn that into code. So instead of having our scheduled task run a skill on a certain... Cadence it basically just turns that skill into code that can actually be executed and then that code is just given from codex To github and then github basically says okay trigger dev you're supposed to run this code You know every hour or you're supposed to run this code whenever someone submits that form submission So if that sounds overwhelming or scary at all, don't worry about it.
It's going to be super simple Just think of it as the idea that you're giving your skills to something else to run it so that it doesn't eat your codex Subscription so that way instead of your usage limit looking like this it will look more like this one down here, which is . So what you'll need for this video is a Codex subscription.
You'll need a trigger .dev account and a GitHub account. That's what we're going to be using. Okay.
So there are three different types of automations that I'm going to show you guys today. And I'm also going to explain the difference. So it's going to be a scheduled automation.
We're going to have a webhook automation, and then we're going to have a Codex SDK automation. So let's start with just number one. This is a scheduled automation, which basically just means we're going to have trigger .dev execute our code that we write on a schedule.
Every 30 minutes, 6 a .m. on Mondays, however we want to set up that schedule, very similar to the way that the scheduled tasks inside of Codex actually work. So the first step of planning out the automation is the planning.
It means we just want to kind of brainstorm with Astra in this case to help us make sure that it fully understands what we want built and to make sure that we're not, you know, missing anything. We're thinking through all of the different scenarios.
And yes, this example is going to be very simple, but it's just to show you how this actually works. So I want to build an automation and I'm going to put this on trigger .dev to actually be hosted there, but you need to help me plan this out and then actually build it. So the first step is just the planning.
I want this to be a morning routine automation. So this is going to go off, let's say 6am and it's going to look at my calendar for the day and it's going to just give me a brief. So we'll have to check my Google calendar and it will just look at the events I have.
And then if there's any additional research or anything like that, that it could do to be more helpful, it can just sort of help me prep for the day. Is there anything else important that I'm not thinking of? And do you understand how this will actually be built out?
And what's cool is it will actually be able to use some of the context that's already in your projects if you are working inside of a project, because you can see the first thing it said is I'm going to check your existing morning routine workflow so that I can actually understand a little bit better how you want this built.
So trigger .dev hosts something called TypeScript, which is just basically a coding language. If you used something like modal, then you would be writing it in Python. So don't worry about this word.
It just is basically the language of the code that we're writing, but. Don't worry about it. So it's explaining now how is this going to work?
So the morning trigger would go off at 6 a .m. America, Chicago time. And then we would look at Google Calendar and we would read today's events.
We would read their descriptions and their times and their attendees and locations. And then it would decide whether the events need prep. So if it's with someone new, we have this stuff that could be helpful.
If it's a podcast, we could have this stuff. So it's going to do a little bit of AI reasoning here. And then it's going to use AI once again to write the short brief.
And then after that, it will send it to me, but I didn't actually tell it where. So it said, where do you want this to be sent? What's the timing?
What's the calendar scope? It's asking me some questions here. So all of these are good thoughts.
I want this to actually be sent to me in ClickUp. I want this to be sent to me as a DM to Nate Herc, so to myself in ClickUp, and you will use the UpIt AI account to actually send this. As far as timing, we want this to be 6 a .m., and let's just have it be on weekdays.
It doesn't really matter to me how long it takes. If I get it at 6 .05 or 6 .10, that's fine. The calendar scope, we're going to use my main work calendar and research boundaries.
Let's just do public web research for now. Later, we could always work in other things like meeting notes and ClickUp and Google Drive and things like that. As far as the research, there's really no reason why you should be spending more than, you know, 25 cents for research at this point, but we can increase that later.
Right now, let's just assume that the calendar is locked at 6 a .m. So don't worry about checking in later. So now that I've given it some more information, I will go ahead and send that off as well.
Now, what I wanted you guys to notice here is figuring out if the automation is one of these two things, which are, it's either a deterministic automation or it's a non -deterministic automation. And so what this means is basically, is it a predictable process or is it unpredictable? And usually the unpredictable automations, when you get into this territory over here, this is when we really need to go for a full agentic harness, a full codex routine, because these are...
very non -deterministic. They're unpredictable. And in this specific example, this was pretty simple.
We basically have, you know, a 6 a .m. trigger. So we have 6 a .m., it goes off.
Then what happens next is we will read calendar. And so that is the next step. And so far, there's not even any AI involved.
Where we start to get AI is in this next step when we sort of do like the decision -making on do we need research and, you know, what would we do? So This is research and this would be an AI step.
So I would fill in this with green just to indicate that this is in fact AI. The other thing that we would need AI for is drafting the message because you can't really draft a message with code unless you were just using explicit placeholders and it's not as flexible. And then the final step is to send that message to ClickUp.
So what I wanted you guys to see here is this is a very deterministic automation because it goes one, two, three, four, five, oops. and it happens in that order every single time. So that is a deterministic flow.
What's not deterministic in here are these specific AI steps. So step number three and step number four are non -deterministic because the research is going to be different every time based on the input that goes in. And then the draft message is going to be non -deterministic because it's different every time based on the research that goes in.
So these are important things to think about because the more deterministic your automation gets, the more of a waste it would be to use Codex to host that. There's no reason to use the full Astra agentic loop inside of Codex if your automation looks like this. 90 % of business use cases or personal productivity use cases are more like this.
They're more of the deterministic automations that help you out and really save time. So anyways, just wanted to call that out. Hopefully you're learning some new stuff in this video.
All right, guys, real quick break for a message from today's sponsor, HyperAgent. Now, I know that a lot of you guys are running AI agencies, and a very tedious part is teaching the same thing over and over again to every new client's agents, because every client wants it done a certain way. So HyperAgent handles that with skills and memories, because you can teach an agent a skill once, like your due diligence framework, or your press release framework, or format, or some API that you always end up wiring in, and it will just keep it in its memory.
And then it will build up memories as it works on things like the client's preferences, their data sources, and how they want things formatted. And then you can watch the whole fleet from a command center that runs eval rubrics and it can do A -B tests so that you can see which agents are actually getting better and what each client costs you to actually run.
They can also sit in your Slack channels and they can jump in when something needs doing instead of just waiting around for you to ask. So if that sounds like something that could be useful for your agency, then check out HyperAgent through the link in the description and you'll get some free credits to start. So thanks again to HyperAgent for sponsoring this part of the video, but now let's get back to it.
So anyways, Codex comes back and says, okay, cool. That gives us a clear plan. Here's exactly what we will do.
Here's the budget. Here's the research. Here's all this stuff that's how it's going to work.
And now let's actually go ahead and start building it. It also calls out this hosting detail, which is that TriggerDev's current free plan scheduling window can delay a 6 a .m. start by up to an hour.
So if we really need this right at 6 a .m., you might have to upgrade your trigger .dev plan. But as far as getting started, you can start on the free plan. All right, so it sounds like you have a good idea of how this works.
What do you need from me? Are there any different API keys that I need to get, or do you already have access to all of these keys? So that's really the next step to be thinking about because if you have been building inside of Codex and you're using a bunch of these plugins, so you've connected to all of your accounts inside of these Codex plugins, those will not transfer over to trigger .dev, which is why I really like to use plugins not very much.
I like to use the .env file and I like to put all my API keys in there so that if I ever need to move them over to Cloud Code or if I need to move them over to trigger .dev. I already have them in one spot and I can just copy and paste them. And I will show you guys how that works later.
But yeah, now that we've done sort of the hard part, the heavy lifting of actually planning out what we want, the implementation is the easy part because now we let Codex actually go ahead and build this out for us. Because as you can see, it says, okay, it has access to Google Calendar, ClickUp, OpenAI, Perplexity, and we will obviously set up trigger .dev.
But basically everything we need to move this over once Codex has built it is already here. If you don't yet have your API keys for Google Calendar or ClickUp, you would just say, hey, can you help me set that up with Google Calendar with ClickUp? And it will tell you exactly where to go and what to click on and what to get.
So getting API keys and getting that set up is not really technical. It's not really a technical lift anymore. It used to be a little more intimidating in the old days.
But now it's so easy. So if you don't have API keys, just ask Codex to help you find where those are. and just go grab them.
But now we're ready to start building. So I'm just gonna tell it, yep, go ahead and start building. And I'll check in with you guys when we're ready to move this over to trigger .dev.
But the one thing I'll say is before we move it into trigger .dev, we wanna have Codex do as much verification on it as possible. So if it's able to test it out and basically fix it before we move it over, then that's good. You know, we've talked a lot about giving agents a way to verify their own work and telling them to verify their own work so that you're not getting their first attempt.
So go ahead and build this out for me. Make sure you feel confident in how it works and you've validated that it will work. before you actually tell me we're going to move it into trigger .dev and then once you're done we will move everything over and host it Now you can see what it's doing is it's building it out and it's testing it.
You can see it's using test -driven development. It is sending DMs. It is looking at how much all this costs.
And it's basically optimizing for what I actually said. It even made sure that the DM was the correct conversation. And the reason why this whole deterministic or non -deterministic thing is important to understand is because yes, you could easily do this as a routine inside of Codex.
But I actually did this before where I had a routine that was very simple like this. And after... about a month, it started to just go rogue.
It's just randomly started to send to different DM channels and it started to send to like the team channel and stuff like that. And the reason for that is because it was an agent on the backend. The agent was just interpreting the message different every time and it just acted differently.
But what we're actually building here is we're building a script. So it doesn't have the option to act differently. We're literally saying, hey, this is what runs and it goes the same way every time.
So in this code, we're basically like hard coding the direct channel with the channel ID and the message ID and everything that gets sent. rather than giving the agent the full connection to ClickUp and saying, hey, just send it to Nate. Anyways, this has just finished up.
So you can see, whoops, that it was built and validated locally and we should have a test brief in ClickUp. So let me check that real quick. Awesome.
So you can see right here that I do have this DM where I see my Tuesday morning briefing. I have my day right here. Every single one of these things has a link to my calendar as well.
If I click on this, for example, it pulls up the actual event in my calendar. And then it also comes back with, hey, here's some useful prep and here are some things to notice. So we know that the ClickUp connection works, we know that the AI is working on the background, and we know that...
the Google Calendar connection's working as well, and it says that everything has been built and validated, and this costed about 1 .33 cents. So us giving it the gate of maxing each run at 25 cents seems pretty realistic. Anyways, now we have to deploy to trigger .dev and validate one run there before we turn on the schedule.
And the cool thing about this is, yes, you're gonna be able to follow this tutorial so you know exactly how to connect to trigger .dev, but if you didn't... So how exactly do I get this automation from the code that you built into trigger .dev? And while it's doing this, let's go ahead and make sure we have a trigger .dev account.
So head over to trigger .dev, go ahead and create an account. Like I said, you can get started for free. Now that I'm in here, you can see I'm on a free plan in this account and I just created a new project up here called YouTube.
And this is what it will look like in order for you to sort of like get everything set up. There's nothing yet in here. So this is how it gets really cool because we're able to basically just connect Codex to trigger .dev and it can basically talk to trigger .dev in order to do all of this.
Now you can also have it connect to GitHub, which is something that I do recommend because that way. GitHub connects to trigger .dev and the three of them talk together. And the reason why we like to use GitHub is because then you can have like different version control and you can have other people more easily contribute to the automation if you need someone else to change it or something like that.
And Codex can connect to trigger .dev and GitHub via the command line tool. So that's what I would probably say next is let's get connected to GitHub and trigger .dev via the command line. and then we can just push our code to GitHub and then trigger .dev will sync with that code.
And what this will do is it will use the CLI and it will prompt you to just authenticate in. So it will do one of those things where it opens up the browser, you sign in with GitHub, you sign in with trigger .dev, and then you come back into Codex and it says, boom, got it, I'm connected. So here is the trigger .dev authorization.
I just have to go ahead and authorize right here. and then it says return to your terminal to continue so codex should have gotten that now and you can see that because my codex is already authenticated to github i didn't have to do that but it would be the same exact flow if you haven't done that yet so now i want you to create a new private repo for this automation in my GitHub account.
And I'm just going to shoot off this message to steer Codex in the right direction now that we know we're connected to these two tools. And you can see that it says the API keys, the calendar snapshots, and anything sensitive are excluded from Git. Even though we're creating it as a private repo, it gets completely excluded.
And that's the whole point of the .env. So what we'll have to do in trigger .dev is we will have to manually move those over. And look at this, because Codex's browser use is so good, it also pulled up my trigger .dev account in this browser.
So if there's anything that you're confused about navigating the trigger interface, you can have it help you out by just clicking around right in there. But it says that we did create this GitHub repo for the morning brief. So basically this repo.
Just think of it like a Google Drive. It holds the actual code and the rules for how this automation runs and trigger .dev will grab this and actually host it. So it's super simple, but also if you make different versions, you will update it here.
So you could roll back to previous versions if you want. And that way, if a team member later wants to take over this automation, all of the details are here and they can contribute to this project. Okay.
So take a look at this. It actually created its own project in my trigger. So it said in morning brief and settings and get is the GitHub repo connected.
So basically what that's saying is, okay, it got into my trigger .dev. You guys saw me create a new project called YouTube, but it decided, okay, I'm going to create my own project. So it made one called morning brief.
And now what we need to do is we need to see if this trigger .dev project is connected to our actual GitHub code base called Morning Brief so that they can sync and talk to each other. So that's what it's asking me to verify. It said to go to the settings in here, but you can see that it says GitHub isn't connected.
So it's actually not syncing to anything at all. So what I need to do maybe is install the GitHub app, but let's see. I'm just going to say, I don't see any deployments.
I don't see any integrations. When I go into trigger .dev, it tells me that GitHub isn't yet connected. That's what I see.
But this is really cool, guys. You can see how proactive this thing is. It actually just went ahead and started doing all of the connections rather than telling me what to do, which is pretty cool.
But every once in a while, it hits a snag and it will just tell you, hey, can you check this? Can you check this? But hopefully with this context, it's going to be able to help out with that now.
And now you can see it's going to open it up. to actually do it itself. So you can see the mouse right here moving.
This isn't me. This is Codex using its browser use to check on all this for us. Okay, so you can see that this says connected and verified and morning delivery remains disabled until the full hosted delivery test passes.
So that's good. And it actually moved it back under the personal account where the GitHub connection already exists and ClickUp still uses UpIt AI. Now...
Let's go in there real quick so I can show you guys something. If I go back into the other project and it actually did it in a different org. So if I go back to my personal org, this is where we should see the morning brief.
There we go. So I was just looking at the completely wrong one. And if I go to tasks, this is where we can actually see the interface of our weekday runs.
And what's cool is it did two different tasks. It did the scheduled one. So this one you can see is the one that goes off at 6 a .m.
Monday through Friday. And then what actually happens when this runs is it calls this other I guess, runner.
So it calls this, and this is the one that has the actual process in it. So it does it in two parts. And that's pretty cool because as you create these longer, more complex workflows, they call individual tasks and pieces that Codex will build out for you.
And it just helps with some visibility. So anyways, what we can do here is if I go into the schedule and I hit test schedule, this basically starts running this. So I'll hit run test.
And now this runs in production. And then what you can see is that it actually calls this other little task. And now this thing is running.
It's showing us how long this is taking. It's going to show us all these little different details so that if this errors, We could copy all this data, give it to Codex and say, hey, this is what happened.
Help me fix this. So you can see that this already finished and we can look through the payload. We can look at the status, which came through as disabled.
And you'll notice that I didn't get a new DM. So we have to figure out why this didn't seem to work. My first thought would be, okay, well, do we have all of our API keys and all of our secrets in here?
And if I go down to deployments, this is where I can click on environment variables. And you can see that we have a bunch of stuff in here that got added today. Today's September 15th.
So Codex actually took our .env. and via the CLI, put everything in here, which is awesome. So we should have our ClickUp IDs.
We have our workspace ID, client ID, all of this stuff should be working in here. So what I would do is I'd say, okay, so I just ran a test run inside of trigger .dev, but I didn't get a ClickUp message. I didn't get anything.
Can you just check and see what happened there? So you guys remember how it came through and said status equals disabled? It's because it had morning brief enabled as false.
So if I go back into our trigger .dev and I go to our environment variables, you can see right here, morning brief, it says false. So we would basically have to come in here, edit this, and we would have to change this to true, hit save. And now if we go back, let's see if this fixes the issue.
So I'm gonna go into the morning brief weekdays and hit test. and go ahead and run that. And there we go.
This looks a little bit different now because you can see it called on our different runner. We can see what's actually going on and we can see this thing actually in real time, sort of like playing out. We got a little bit of a green message here.
We get output equals delivered. Let's open up my ClickUp, see was this a new run? Okay, well, unfortunately this still doesn't look like it was a new run.
So once again, we have to go figure out why this didn't work yet. Because if you guys remember, it worked when Codex was testing it locally, but it didn't work yet in... production so okay that run seemed to work it showed that we actually got the output but i didn't get any dm and click up so take a look at that run and help me figure out how do we fix this okay that's really interesting what happened was The run found today's earlier test message.
So it skipped sending a duplicate because it would have been essentially the exact same message. So it seems like that run didn't actually fail. It was more so done by design.
You can see the existing message was sent at the 12 .01 and we just tried to run a new one at 12 .33. So it didn't get sent. That's why it's always important that when you're having AI build you automations and build you code, you don't have to know what every single line is doing, but you do have to test this stuff out to figure out how it works and why it does what it does.
I mean, look how powerful this is. It's basically able to deploy everything, debug everything, move around in the interface, and then just test it all for me. And we're just using our natural language and we're using our intent to drive all of this.
This is so much quicker than the way I used to have to build automations. It worked in this variable that shows that if it was already delivered and it got triggered twice for some reason to not send a duplicate message. So duplicate prevention remains intact.
I think it did a really good job there. But I do want to prove to you guys that this works. So I'm telling it to override that just so we can see that it works as expected.
And then we'll move on to the next automation. There we go. We can now see that we got the hosted proof test for the morning brief.
And now we can feel better about turning this thing on inside of trigger .dev and knowing that it will actually have all the connections set up because we've seen it in here. We've tested it. We know that all of the environment variables are also moved over.
So we are all good to go. All right. So we took care of this scheduled type of automation.
Let's look at one that is. triggered by something. So typically this is triggered by a webhook.
So we're gonna go back into Codex and we're just gonna start having it do two things for us. It needs to build sort of like a very simple front end that will actually be our trigger for this specific example and then we'll build the backend too. So I'm actually gonna try to do this in one fell swoop.
I'm gonna do a slash goal and here we go. So now I want to build a webhook triggered automation inside of trigger .dev. So this is kind of a two -parter.
The first part is We need to use, or sorry, I need you to help me build just a very simple local host that is sort of like a form submission that you might see on a website. Collects information like the name, the email, and team size and what they're looking for.
So a simple landing page, a simple form that we can fill out. And then when the user hits submit on that, that's what I want to trigger the actual automation on the backend that we're going to build and put in trigger .dev. So basically what I want is for that automation to just send me a ClickUp DM.
So same DM as before. And I want this one to say, hey, you got a new form submission. It's for this person.
Here's what they asked for. And here is how I recommend you reach out to them. So sort of like just creating a draft.
So I'm gonna shoot that off and it might have some questions for us. But this is a very simple use case just to show you how it works with a webhook. But this is still a very much a deterministic automation.
Even though it is AI, it is still deterministic. So let me show you real quick what this one looks like. This one is a webhook trigger, so this is just going to be a form submission.
That is basically what kicks this thing off over here. From the form submission, what happens is it's going to actually read the form, and it's basically just going to have to do one thing, which is create the actual message that will go to us in ClickUp, and then it will basically send it to us in ClickUp. So it takes a very similar shape as to what we've already seen, except for instead of going off on a schedule at 6 a .m., it goes off based on the actual action.
which is triggered by us. And then once again, the only time we actually see AI inside of this process is just here. Now you could actually do this with no AI.
If you wanted the form submission to just shoot you a message and click up, you could do it with placeholders and you could do that. You'd save yourself some money and some time because there'd be no AI message or sorry, there'd be no AI step. And that would be a hundred percent deterministic every single time.
Now, obviously there are some edge cases you might want to think of, you know, how do you build a form so that they can't. you know, spam it a thousand times in a second. How do you build the form so that if you're expecting an email field, you're actually going to get only email fields.
There's a lot of other edge cases to think through, but what's cool about that is after you build this, you could say, okay, cool. Now spin up 50 different sub -agents and have all of them test this thing, try to break it, and then let me know what you find. And you can really stress test and QA your own automations before you actually have.
any sort of human or customer find these bugs or anything like that. So that's pretty cool. It's going to spin up a local page.
It's going to use the existing trigger .dev deployment on the backend. And now, because we've already set up the connection with like GitHub and trigger .dev, all of the automations we want to build in the future are going to be much, much easier. So I'm basically just going to check in with you guys when this one is done and show you how that works.
Okay, so it says that this is done. You can see that we have this form here to fill out. It says that it has built and verified this end -to -end.
So submitting it now will start the hosted trigger .dev task. It will generate the outreach recommendation and it will send everything to ClickUp. So let's go ahead and real quick check in trigger .dev.
We do have this new one right here. I'm gonna refresh just in case. And you can see that we have this new one called form submission.
It has already been triggered a few times it looks like. Actually, let me just zoom out so that we can see this better. It has been triggered five times.
So this was Codex testing it. And now let us go ahead and test it ourselves. So I'm gonna go back into Codex.
I'm gonna fill out this form. So we're just gonna say Alex Morgan, alexatcompany .com, team size, we will just put 201 plus. We are spending so much time on making hamburgers and it's just becoming a real bottleneck.
So I'm looking to see if we can automate that. And let's go ahead and shoot that off. What do we get on this front end?
Your request is in. Let's go back to trigger .dev. Let's see if we get some sort of run.
I'll go back to the tasks. We should see, it looks like there's a new one executing right now. If I click into this run, we should see that all of this is actually going on.
So that proves that this webhook has been set up correctly. Now in the old days, we would have had to set up the URL and kind of sync them together and like build out the payload. But we don't have to do that at all.
And this is the payload basically, like the information that comes through. And now we have the output. Let me check and see if we got this in ClickUp.
Sweet, okay, so we actually got a lot of these. These are all of the demo examples that it... tried, you know, the new form submissions, but this is the one that we just submitted.
You can see right here, Alex Morgan, here's the email, here's the team size. Now this took no AI. This is what I meant when I said that this could be just placeholders.
So if you wanted to just get this notification, no way I needed, but here's where we needed AI, the recommended outreach and the email draft. And this is what had to be obviously generated with artificial intelligence. So that's kind of the trade -off there, but super simple, super easy.
That took me no time to build. And I barely had to do anything as far as like, wiring things up by hand.
So that is a web book automation that doesn't obviously have to be just a form submission. That can be a new record in the CRM. That can be a new email entered the inbox.
There's so many different event -based triggers that you can have for a web book style automation. By the way, guys, I've got this completely free SOP for you about getting your first AI automation client. It's going to go over the exact steps that has been proven for hundreds of our AIS Plus members to get their first paid gigs.
It goes over the one -sentence service pitch that can get you started today, why your first client should cost you money, the five -minute video that answers can this person actually deliver before you've actually received any money, what to do when you have zero case studies. There's so many good things in here that are going to help you out, even if you already do have clients.
I would recommend grabbing this because like I said, it's yours completely free. So if you want to grab this, there's a link for it down in the description. Let's get back to the video.
All right, and for this last use case, now that we've done the webhook as well, this one's a little bit special. And this is when you kind of want that full agentic loop that you're used to getting inside of Codex, but now you're getting it programmatically. And that is through the Codex SDK.
So a really good opportunity to see if you want to actually use the Codex SDK is when you need to bring something that might be an already existing routine into something like trigger .dev. Now, the thing about this is... Most of the time, if you're running an automation in a scheduled task inside of Codex, I would recommend you keep these as a Codex scheduled task, because then it actually eats away at your subscription.
But if you need to do this at scale and you can't use your subscription programmatically, then you probably want to build the automation with the Codex SDK and then host it on something like trigger .dev. So if that ever does become the case, you kind of get the full agentic loop. So here's what that might look like.
We saw these first two examples. Now, what I'm going to do here is this is going to be a scheduled task. So we're just going to call this Actually, let's just call this every 30 minutes.
And I actually do this for real inside of a scheduled task inside of my codex where 30 minutes it wakes up. And we basically just have this full agent. And what it does is it basically, it looks at my, I'm just gonna call this an agent because it does a lot of things.
It looks at my Alpaca account. And actually, let me just like go down here and make some tools. Just pretend that these are tools.
So it has to like check Alpaca, which is where I have like some trading going on. And my agent here helps me. trade.
It will also do research. It can also just look at past logs and stuff like that. So it's leaving logs for itself every time so that the next time the agent wakes up, it's not completely stateless and just doesn't know what to do.
So the reason why this is the SDK rather than just being more of one of these deterministic AI automations. is because we don't know how many times it might need to look at the logs and read things or look at the research or check back in an alpaca. If it's doing research for 10 minutes and then it's like, wait, let me just check the current holdings one more time because things may have shifted.
This, it has the ability to basically just go back and forth. You know, it can go like this and then this and then this and then this and then this and then this and then this. And it's basically an agent and it has that.
luxury. And then what happens is it essentially just sends an email with a recommendation. So I'll just call this email and it sends that to Grokbot.
And then Grokbot actually places the trade because opening eye models and cloud models don't actually let you trade anymore. They just won't do it. I think it's because all this security stuff is going on, but Grok still lets you trade.
So my Grokbot is the one placing the trades and Astra is doing all of this heavy lifting research. Now, yes, you could do this exact same sort of thing in a deterministic flow, but that would just look different. It would basically be a predetermined amount of research so for example it could hit like a research step or maybe it hits you know two research steps so i'm just going to like sort of demonstrate this like this or maybe it does two different like research sources so maybe this one is fire crawl and this one's perplexity or something and then it basically will send it to an agent to um look at the research and can create the draft create the email and then send it off But what if it looks through this and it's like, wait, I want to do some more research because now the AI agent has analyzed it and it's like, wait, let me do some more.
We would have to work in somehow the ability for the agent to loop back and do more research. And that's essentially why we would just use something like this, where we're now using the SDK to give us that sort of autonomy. So let's go ahead and build that out real quick.
Now, this would be a very similar process where I would like you to say, hey, I want you to interview me about this process. I want to get very clear on what this does, especially the more autonomous your systems get. There's more room for error.
There's more room for, you know, you're increasing the risk, you're increasing the cost, you're increasing complexity, you're increasing the maintenance, you're increasing a lot of things. So build the simplest solution possible and only move up the sort of , as I call it, when you truly need that functionality.
So I would go through this whole process of interviewing to get what I want, but we have this luxury here of all of this is already set up because we have these routines going. You can see that I have this thread called challenge thread where I'm doing this actual trading and you can see that every like 30 minutes or so, it's basically just starting this routine and it's doing the whole agentic loop.
We see that one is actually running like right now and this is the, this is Codex. This is Codex working and we're basically just trying to move this over to trigger .dev. Now I'm not really wanting to, I obviously want to keep that using my subscription, but for the sake of the demo.
So what I need you to do now is I want you to build me a Codex SDK. automation and we're going to host this inside of trigger .dev now what i want to do is i basically want to transition the astra trading challenge that thread i want to move that routine over to trigger .dev so we basically wake up like every 30 minutes during trading hours one check before one check after and we do this research loop we check out paco we check the logs so familiarize yourself with that actual process and then just turn this into a Codex SDK automation for me and host it in trigger .dev.
Let me know if there's anything else that you need to build this. So once again, the hardest part is already done here, and now we're just gonna get that built out, so I'll check in with you guys when this is all done. Okay, so this run took about 15 minutes, a little over 15 minutes, and we can see now that this is ready for our review.
It did 44 passes, or 44 tests, and it paused the old desktop routine, which I'm gonna say, you know, I don't want it to pause that. This was just a demo, so anyways. It was being pretty proactive there though.
But anyways, what it did is it made a new project. So it created a full new one rather than what we were doing earlier. And I'm actually just gonna open this up full screen in my desktop over here.
Give this a quick refresh. You can see what it did is it basically made a few different like tasks or runners or whatever you wanna call them. And they kind of call on each other.
So you can see here, there's the check. This ran 18 times. Then we have an install plan.
We have a pre -flight and we have a proof. So I'm not exactly sure the right order to run this in, but this is what it did. And if I go to the runs, we can see exactly what happened.
So it basically runs, you know, these failed, these completed. We've got these checks. So what we're gonna wanna do is we're gonna wanna figure out what does each one of these do?
So I'm gonna go ask CodexNet real quick. So I can see that you actually created four different tasks. We've got a check, an install plan, a pre -flight and a proof.
Can you just explain to me what these are? and how they work together, and how these use the Codex SDK to give us sort of that full agentic loop that we're looking for here. Okay, so AstraCheck is the actual recurring worker.
That is the one that should fire on the schedule. The other three help it do things. So the preflight checks the Codex runtime.
Alpaca connection, SIP market data, policy files, and the checkpoint storage, and it can optionally make a small model test call. So this really only needs to run during setup or troubleshooting. We have proof, which runs the full research and reporting workflow, including the test label email and ClickUp delivery.
It prevents actionable trade tickets during the test, and this will run before enabling the routine. currently disabled after verification, the install plan during setup, and then the check at each scheduled check. So it's actually interesting.
It made all of those to help it build and to check, but now I'm not sure because each check now follows this process where we have, it loads up the context, it asks Codex what needs investigation, it finds the evidence, it has Codex evaluate all of that, and this is with the SDK, of course, it validates and delivers, and then it saves the handoff.
So the agentic part is Astra choosing what to research using web tools. doing deeper evidence and adjusting its conclusions based on the results, which is pretty interesting. This is the only one that will actually run now that this is all built.
So I'm going to go back into here and we're going to go to Astra check and we're going to hit test and just test this thing out right here. Now, look at this. It just called this attempt right here.
And we open this up. We can see everything that's actually going on. Now, this is pretty cool.
The reason why this did nothing is it actually sent this payload over, which was like the time and the date. And then the output was, hey, this is early because this was set up by Astra in a way where it's supposed to check in during market hours. And right now the market has already closed.
So the next scheduled run is until tomorrow morning before the market opens. So that's why it basically fired. And it was like, oh, you know, this actually isn't right.
I'm not supposed to run yet. So I'm outputting the word early. But I do know that this works because if I go into my ClickUp thread where I'm actually getting these notifications every day from the actual routine.
You can see that these started to come in. You can see we have the test migration here, 341, 347. We have another test migration for Nate's review.
It's doing the research. It's giving us assessments. It's linking things.
It's looking at our account. It's pulling in all the sources. It did another one at 352 for the market close.
So this is currently working. And what it's actually doing is it is messaging Grokbot. This is my trading Grokbot that actually places these, you know, trades based on getting an email.
So everything transferred over to the point where it's getting these test migration reports, as you can see, because what's going on is. Trigger .dev automation with the Codex SDK, like it said, it's checking, it's doing research, it's looking at the evidence, and then it's making a recommendation, and it's sending it to ClickUp, but also as an email to my Grok bot.
So you can see we now have already set that up in trigger .dev to basically mimic a codex routine with Astra on the backend with a full codex agentic loop, but we could now trigger this programmatically and we could do it by webhooks and on different schedules. And like I said, you only would really do this when you need it to truly be programmatic and at scale because otherwise you want to throw it on your subscription because paying for Astra via API credits is obviously more expensive than paying for Astra via subscription.
But that is how these three types of automations differ. And now I can come back in here and I can cross out Codex SDK. But anyways, guys, that is going to do it for this one.
So I hope that you enjoyed and you learned something new. And if you did, please give it a like. It helps me out a ton.
If you guys want to check out any more Codex content from me, then go ahead and check out this playlist right here. All of that's about Codex and Astra and more stuff like that. So hope to see you guys over there.
Thanks for making it to the end. Take care.
The Hook
The bait, then the rug-pull.
Codex will happily run your scheduled and event-triggered automations forever, right inside its own chat thread. The problem, Nate Herk opens with, is that every one of those runs quietly counts against your weekly usage limit. His fix: let Codex do the planning and building, then hand the finished automation off to Trigger.dev to actually live and run.
Named ideas worth stealing.
05:05concept
Deterministic vs. Agentic Automation
A test for whether a task should be a fixed step-by-step script (with AI only at judgment steps) or a full autonomous agent: is every step's order and count predictable in advance?
Steal fordeciding whether any recurring internal or client automation is being over-built
01:36list
Three Automation Types
- Scheduled
- Webhook
- Codex SDK
The three ways an automation can be triggered and hosted outside a Codex chat thread, in increasing order of cost and autonomy.
Steal forcategorizing which pattern a new automation idea actually needs before building it
31:40concept
AI Systems Pyramid
Build the simplest deterministic version of an automation first, and only climb toward more autonomous, agentic versions when the simple version genuinely can't do the job, since autonomy adds risk, cost, complexity, and maintenance together.
Steal forscoping any new agent or automation project before writing code
How they asked for the click.
VERBAL ASK
35:02next-video
“if you guys want to check out any more Codex content from me, then go ahead and check out this playlist right here”
Soft sign-off: asks for a like, then points to his Codex/Astra playlist. The heavier pitches (Hyperagent sponsor, free First Client SOP) both land mid-video, not at the close.
MENTIONED ON CAMERA
Visual structure at a glance.
