My approach to automation has changed. I now spend most of my time using Codex to build the code that connects the systems a workflow needs.
For many projects, the starting point is straightforward: understand the task, identify the required services, configure their credentials and permissions, and build the integration in the project itself. Python can be a good fit for that work. If the application already uses another language, I work with the stack that makes sense there.
The important shift for me is that I can describe the process, work through it with a coding agent, and keep iterating against real files. The result is code I can inspect, test, and maintain alongside the product.
The 5-Step Agentic Pattern
I find this a useful way to think about a workflow that needs AI reasoning:
- Sense: Receive a message, event, file, or form submission.
- Think: Interpret it using the relevant context.
- Decide: Choose a next action or ask for missing information.
- Act: Call a tool or service within the permitted scope.
- Check: Inspect the outcome and record what happened.
Some automations only need the first, fourth, and fifth parts. If the process has fixed rules, ordinary code may be enough. An AI agent can help build the automation without needing to run inside every execution of it.
That distinction matters. I want reasoning where it adds value and predictable code where the action is already known.
What Businesses Should Be Doing Right Now
Start by looking for repeated work that takes time or delays a response. Then describe the process before selecting a platform:
- What starts the workflow?
- What information does it need?
- Which systems does it read from or write to?
- What should a successful result look like?
- What should happen if a step fails?
- Which decisions need a person?
These questions give the coding agent something specific to build. "Automate our leads" is an idea. "Save a form submission, notify the owner, and acknowledge the visitor" is a process.
A Practical Example: My Website Lead Emails
A simple example is the lead workflow I built for JedAI and JedAI Chat.
When someone submits a lead form, the application saves the inquiry and attempts to send me a Gmail notification containing the details. It also sends the visitor a confirmation after the owner notification is accepted. On JedAI Chat, the confirmation includes a project questionnaire matched to the service they selected.
The sequence is:
Visitor submits a form
→ Validate the submission
→ Save the lead in the site's database
→ Send the owner notification through Gmail
→ Send the visitor confirmation
→ Record delivery outcomes
This implementation uses JavaScript/Node.js with Nodemailer and Gmail SMTP. The broader method applies across languages: use Codex to help build a direct integration suited to the application.
The questionnaire selection follows fixed rules. It does not need a model to decide which link belongs in the confirmation. That makes this an example of an automation built with AI assistance, rather than an autonomous agent reasoning through each signup.
Get the Connections Right First
Before building, I work out which credentials and access the process requires. Some services use API keys; others use OAuth, database credentials, or a different authentication method. The Gmail sender in this example uses an app password configured on the server.
Those credentials belong in the environment or a secret store. The agent needs to understand which connections exist and how the application should use them, without secret values becoming part of the public code or the article.
Access is only part of the setup. I also need the expected inputs, the relevant data definitions, and the intended behavior at each step.
Test the Whole Path
I verified Gmail delivery locally for this workflow. Public email delivery still needs verification on the deployment host; local success alone does not establish that the hosted sender can reach Gmail. Hosting network restrictions can prevent that connection.
The distinction I care about is simple: a lead saved in a database is not proof that an email arrived.
The implementation saves the inquiry before attempting delivery and records failures so the inquiry remains available for investigation and a later retry. It also includes duplicate-submission handling to reduce repeated sends.
A useful check follows the actual path: submit a form, confirm the database record, verify the owner notification, open the visitor's confirmation, and check the questionnaire link. Failures deserve the same attention as the successful path.
How I Think About the Choice
My preference is to build directly with Codex when I want the workflow to live inside a project I control. That gives me a place to keep the business rules, error handling, and review history together.
It still takes engineering. Credentials do not replace validation, deployment configuration, or a clear understanding of what should happen. A coding agent helps me develop those pieces; I remain responsible for testing the result.
Keep the Human Decisions Visible
As the workflow becomes more complex, I want the agent to tell me what needs my input. It should ask useful questions when requirements are missing or a choice affects the product.
A skill file can capture the reusable procedure. A script can carry out a defined action. A model can help interpret an ambiguous request. Each has a role, and the design should make those roles clear.
That is what the shift from workflow to workforce means to me now: turning a repeated business need into a maintained system, with the right balance of code, reasoning, and human direction.