Halilcan Soran

Tag: Codex Automations

  • OpenAI and Dell Are Bringing Codex On-Prem and That Is a Bigger Signal Than the Headline

    OpenAI and Dell Are Bringing Codex On-Prem and That Is a Bigger Signal Than the Headline

    OpenAI Dell Codex on-premise enterprise deployment diagram

    OpenAI and Dell announced a partnership to bring Codex into hybrid and on-premise enterprise environments. The headline reads like another infrastructure deal. It is not. The OpenAI Dell Codex on-premise story is an admission that the real ceiling on AI coding agents in regulated enterprises was never the model. It was data gravity and where the agent is allowed to execute.

    I have been waiting for one of the frontier labs to say this out loud.

    What it actually does

    The partnership packages Codex to run on Dell infrastructure inside an enterprise boundary. That means the coding agent can sit next to the source code repositories, the build systems, and the production data it needs to reason about, without that material crossing into a public cloud endpoint.

    Practically, you get Codex behavior with private deployment posture. The agent can read your repo, propose changes, run tests, and interact with internal systems while the model inference, the context window, and the working memory stay on infrastructure your security team already owns and audits.

    This is not a stripped-down Codex. It is the same agent capability, moved to a place where regulated industries can actually use it. Healthcare, defense, banking, public sector. The places where a senior engineer cannot paste a function into a public chat window without filing an incident report.

    Why the OpenAI Dell Codex on-premise move matters

    Every regulated enterprise I hear from has the same problem. They are not blocked on whether Claude or GPT or Gemini is the best coder this week. They are blocked on a simpler question. Can the agent see the code at all.

    If the answer is no, model quality is irrelevant. You end up with developers using public AI tools on personal laptops for snippets, manually retyping the output into the secured environment, and pretending this is a workflow. That is the actual state of AI coding adoption in a lot of large orgs right now. I am not exaggerating.

    Moving Codex on-prem changes the question from can we use this to how do we govern this. Those are different problems with different owners. The first one stalls for two years in legal review. The second one gets a project plan.

    There is a second signal here that matters more than the deal itself. OpenAI is conceding that the pure SaaS-only posture does not work for the highest-value enterprise segments. Anthropic has been hinting at the same thing with their enterprise services arm, and Microsoft has been quietly threading this through Azure for a while. The frontier labs are realizing that data gravity beats model gravity in the enterprise. The agent has to come to the data, not the other way around.

    The trade-off is real. On-prem deployments mean slower model updates, more operational burden on your platform team, and capacity you have to plan for instead of renting elastically. You give up the magic of always on latest. You get back the ability to actually use the thing.

    What I would do with it this week

    Even if you cannot deploy this tomorrow, you can get ready. The teams that move first will be the ones who did the boring preparation work before the procurement conversation started.

    Map where your code and pipeline data actually live. Not the architecture diagram version. The real version. Which repos are in GitHub Enterprise Cloud versus self-hosted. Which CI runners can reach which networks. Which production data the agent would need to read to be useful for debugging versus generation. If you cannot answer this in a meeting, the on-prem agent conversation is going to stall on day one.

    Write down the three coding tasks you would actually want an agent to do inside the secured environment. Not refactor our monolith. Specific things. Generate Power Platform solution components from a spec. Write the boring integration tests nobody wants to write. Triage failing pipelines. Pick three and put numbers on them. Hours saved, error rates, anything concrete. If you are thinking about where agents sit in a broader orchestration design, the distinction between single-agent and multi-agent architectures is worth settling before you scope the deployment.

    Talk to your security and compliance partners now, before the vendor demo. The fastest path to a stalled pilot is showing up with a tool and no answer to the data residency, audit logging, and model output review questions. I have seen this pattern repeat across orgs and the result is always the same. Six months of slideware, no deployment.

    Finally, watch what this does to the Copilot conversation. If Codex can run on-prem next to your code, the bar for what Microsoft has to offer inside the same boundary goes up. That is good for everyone building inside enterprise walls. The Anthropic acquisition of Stainless is worth watching in this context too, because the SDK layer that governs how these agents are called and integrated is quietly becoming as strategic as where the model runs.

    The era of AI coding agents being a public-cloud-only story is ending, and the orgs that prepared their data and governance posture early are going to look very smart in twelve months.

    This post was inspired by OpenAI and Dell partner to bring Codex to hybrid and on-premise enterprise environments via OpenAI.

  • Scheduled Codex Runs Are the Missing Piece Between Chatbots and Real Automation

    Scheduled Codex Runs Are the Missing Piece Between Chatbots and Real Automation

    Codex automations scheduled ai runs replacing recurring jobs

    I came across a post from OpenAI about Codex Automations the other day, and it reminded me of a pattern I keep seeing people miss. Everyone is obsessed with chatbots. Meanwhile the real unlock is boring and familiar to anyone from the Power Platform world. It is the schedule. Codex automations scheduled ai runs are the bridge between cool demo and something that actually replaces a recurring job.

    Most AI tooling still assumes a human is in the loop pressing a button. That assumption is the ceiling. Break it and the shape of what you build changes.

    Why a scheduled AI run is different from a scheduled flow

    A scheduled Power Automate flow is deterministic. Same trigger, same actions, same branches. You can draw it on a whiteboard before it runs and the drawing will be correct. I have written about this before. If you can fully diagram the execution path before it runs, it is not an agentic workflow. It is a flow.

    A scheduled Codex run is the opposite. The trigger fires on a schedule, but the work happening inside is a reasoning step. The model decides what to read, what to compare, what to summarise, what to flag. You are not wiring actions. You are wiring a recurring thought.

    That sounds fluffy. It is not. It changes what workloads are worth automating at all.

    The workload shape where Codex automations scheduled ai runs actually fit

    Here is the shape I look for. The task runs on a cadence. The inputs vary in structure every time. The output is a judgement, a summary, or a prioritised list. No two runs look the same but the goal is identical.

    Think about the recurring jobs that never got automated because the logic was too fuzzy. The weekly review of open pull requests that actually need attention. The Monday morning scan of overnight alerts to decide which three matter. The monthly pass over a folder of documents to flag what changed in a way a human cares about.

    In Power Automate you would try and fail. You would end up with a flow that emails everything to a human who then does the real work. The flow is a courier, not an automation.

    A scheduled AI run is different. The reasoning is the automation. The delivery is the courier part.

    What I would build with this tomorrow if I had it internally

    A daily 7am run that reads the previous day’s pipeline run logs across a set of flows, clusters the failures by likely root cause, and posts a short Teams message with the three things worth looking at. Not the raw error list. The interpretation.

    A weekly pass over a shared folder that produces a diff in plain English. What changed, who changed it, whether it looks like policy drift or normal edits.

    A monthly review of connector usage that flags flows quietly heading toward platform-level throttling before they break in production.

    None of these are chatbots. None of them need a human to press a button. All of them are reasoning tasks that happen on a clock. That is the fit.

    Where Power Automate still wins and where it does not

    Power Automate wins the moment the work is deterministic and the integrations are inside the Microsoft estate. Approvals. SharePoint updates. Dataverse writes. Email parsing with known templates. Anything with governance, DLP, and environment strategy attached. A scheduled AI run from outside the tenant does not solve those things. Power Automate does.

    It loses the moment the work is a judgement call on messy inputs that change shape every run. That is where a scheduled Codex or Claude run wins by a wide margin. Trying to force that into a flow gives you the courier pattern. Useful, but not automation. Latency Is the Quiet Killer of Agentic Workflows and the same principle applies here — the more reasoning steps you stack inside a scheduled run, the more carefully you need to budget what actually happens inside that window.

    The interesting move is using both. The scheduled AI run produces the judgement. Power Automate delivers it, logs it, routes approvals, writes to the system of record. The reasoning layer decides. The execution layer acts. I have said this more than once and I will keep saying it because most teams still collapse the two. If you are thinking about where Workspace Agents compare to Power Automate in this picture, that framing is worth reading before you decide which layer owns the work.

    If you already think in triggers and schedules from the Power Platform world, you are better positioned than most to use this well. You know what a cadence looks like. You know what idempotent means. You know why retry logic matters. Now the thing running inside the schedule can think. That is the shift.

    Stop waiting for someone to press a button.

    Frequently Asked Questions

    What are codex automations scheduled AI runs and how do they work?

    Codex automations scheduled AI runs are recurring AI tasks that fire on a set schedule, where the model performs reasoning rather than following a fixed, pre-wired set of actions. Unlike a traditional scheduled flow, the AI decides what to read, compare, summarise, or flag each time it runs. This makes them suited to tasks where the inputs vary but the goal stays the same.

    How do I know when to use a scheduled AI run instead of a Power Automate flow?

    If you can map out every branch and action of a task before it runs, a standard flow is the right tool. When the output requires interpretation, prioritisation, or judgement based on inputs that change each time, a scheduled AI run is a better fit. Tasks like triaging alerts, reviewing documents for meaningful changes, or summarising error logs fall into this second category.

    Why does a scheduled Power Automate flow struggle with fuzzy or variable logic?

    Power Automate flows are deterministic, meaning they follow the same paths every time regardless of context. When the logic requires understanding nuance or making a judgement call, the flow typically ends up forwarding everything to a human rather than completing the work itself. The flow becomes a delivery mechanism rather than a true automation.

    When should I consider replacing a recurring manual review task with an AI automation?

    If a task runs on a regular cadence, involves inputs that vary in structure, and produces an output that is a summary, ranking, or decision rather than a fixed result, it is a strong candidate for AI automation. Examples include weekly pull request reviews, overnight alert triage, and monthly document audits where a human currently does the interpretation work.

    This post was inspired by Automations via OpenAI.