DEV Community: Paulo Victor Leite Lima Gomes

coding agents made repositories the security boundary

Paulo Victor Leite Lima Gomes — Wed, 10 Jun 2026 00:03:52 +0000

GitHub shipped a small changelog entry this week that says more about the future of coding agents than most of the launch demos.

Security validation for third-party coding agents is now generally available. Not just for GitHub's own Copilot cloud agent. For third-party agents too, including Claude and OpenAI Codex.

The feature sounds boring in the best possible way.

When an agent creates code, GitHub can run CodeQL, check new dependencies against the GitHub Advisory Database, and use secret scanning to detect tokens, API keys, and other sensitive material. If it finds a problem, the agent tries to fix it.

That is not the flashy part of agentic coding.

It is the important part.

Because once agents are allowed to act inside repos, the question stops being "which model wrote this diff?" and becomes "can the repository apply the same policy to every automation actor?"

authorship is the wrong abstraction

We still talk about generated code as if authorship is the primary thing that matters.

Was this written by Copilot? Claude? Codex? A human with tab completion? A human who pasted something from a chat window and cleaned it up? A junior engineer following a Stack Overflow answer from 2018?

Those distinctions matter for procurement and product marketing. They matter less for the repository.

The repository has a simpler problem: a change is trying to enter the system. It may introduce a vulnerability, add a risky dependency, leak a secret, violate an internal rule, or be perfectly fine.

That is why the GitHub change is interesting. It moves the useful boundary from "our approved coding assistant" to "any coding agent operating in this repository."

the agent is now an actor

For years, repository automation was mostly boring and legible.

CI ran tests. Dependabot opened dependency updates. Release bots bumped versions. Linters complained. Security scanners commented. Humans reviewed. The automation could be annoying, but its shape was predictable.

Coding agents are different.

They do not merely report on the repository. They edit it.

They read issues, inspect files, modify code, add tests, update dependencies, and open pull requests. That makes them closer to a contractor than a linter.

And like every contractor with write access, they need boundaries.

Not vibes. Boundaries.

What tools can they call? What data can they read? Which secrets are visible? Which checks must pass? Who approves the final merge? How do we audit what happened later?

These are not philosophical questions. They are repository administration questions.

The funny part is that this makes agentic coding feel less futuristic and more like boring enterprise software. Identity, authorization, audit logs, policy inheritance, defaults, exceptions, and enforcement.

As usual, the boring part is where production starts.

security checks should not depend on vendor loyalty

The worst version of agent governance is vendor-specific policy.

Copilot-generated code gets one security path. Claude-generated code gets another. Codex-generated code depends on whatever the team remembered to configure. A local agent running from a developer machine is treated as a human diff because nobody knows what else to do with it.

That does not scale. It also creates the wrong incentive: teams argue about which agent is safe instead of making the repository resilient to generated work in general.

The security posture should not be:

"We trust this model."

It should be:

"We do not allow unvalidated changes through this boundary."

Those are very different statements.

The first one turns model selection into a security control. That is weak, because models change, vendors change defaults, prompts drift, and generated output is still output.

The second statement is boring and robust. Every change gets checked. Every actor hits the same gates. The repo enforces policy regardless of whether the diff came from a human, a first-party agent, or a third-party one.

That is the direction this needs to go.

automatic remediation is useful, but weird

The part that made me pause is not that GitHub runs security analysis.

It is that, when a problem is found, the agent attempts to resolve it before finalizing the pull request.

That is useful. It also changes the review loop.

Traditionally, a scanner reports an issue and a human fixes it. With agents, the loop can become: tool complains, agent modifies code, tool checks again, agent modifies code again, then the final diff appears for review.

That is probably right. It is also a reason to be more disciplined about logs and provenance.

If an agent introduced a dependency, the scanner flagged it, and the agent replaced it with another one, the final pull request may only show the end state. The interesting part might be the path it took to get there.

For small bugs, nobody will care.

For security-sensitive changes, regulated environments, and expensive incidents, people will care a lot.

This is where "agent wrote code" becomes too vague. We need to know which agent acted, under which permissions, which tools ran, and which checks were authoritative.

That sounds like paperwork until the first incident review.

Then it sounds like the minimum viable truth.

this is a platform-team problem

One pattern keeps repeating across the agent tooling news: the useful features are becoming platform features.

Security validation. MCP server configuration. Repository-level review settings. Agent skills. Cost controls. Sandboxes. Audit trails. Hooks before and after tool use.

These are not features an individual developer should be hand-rolling for every repo.

If a company has hundreds of repositories, the platform team needs to answer boring questions. Which agents are allowed where? Which validations are mandatory? How are secrets isolated from agent execution? Can the company prove that the same rules apply across repos? Who owns the policy when it breaks a team at 5 PM on Friday?

None of this looks like the AI demo, but it decides whether agent adoption becomes productive infrastructure or a pile of clever one-off workflows.

the repository is becoming the enforcement layer

I like this GitHub change because it points to the right mental model.

The agent is not the trust boundary.

The repository is.

That does not mean the agent can be reckless. Agent identity, sandboxing, tool permissions, and prompt controls still matter. But the repository is where work becomes part of the system. It is where code review, CI, security scanning, branch protection, dependency policy, and audit history already meet.

So it makes sense for agent governance to land there too.

This is also a good reminder that "AI-native development" will not replace the old software delivery machinery as quickly as people think. It will mostly increase the load on that machinery: more pull requests, more generated dependencies, and more plausible mistakes arriving faster than reviewers can comfortably process them.

The answer is not to make every human reviewer faster by sheer force of will.

The answer is to move the obvious checks closer to the boundary and make them consistent.

what i would do now

If I were responsible for agent adoption in a real engineering organization, I would start with the repository policies before buying more seats or enabling more tools.

Inventory which automation actors can open pull requests today. Include the boring ones: dependency bots, release bots, internal scripts, CI workflows, and any agent experiments running from developer machines.

Then make the entry rules explicit.

At minimum, I would want mandatory security scanning, dependency checks, secret scanning, branch protections, and a clear distinction between "agent may propose" and "agent may merge." I would also want logs that make agent actions reconstructable later.

I would avoid making this a model-ranking exercise.

The question is not whether Claude, Codex, Copilot, or the next thing has the best benchmark score this month. The question is whether your repository can safely accept work from any of them under a policy you understand.

That is the difference between a demo and an engineering system.

the punchline

The interesting thing about third-party coding agents is not that they can write code.

We know they can write code.

The interesting thing is that they are becoming normal actors inside software delivery. Once that happens, the repository has to become stricter, not looser. The more autonomous the actor, the more boring the boundary needs to be.

GitHub extending security validation beyond its own agent has a large implication: agent governance cannot be a product-specific afterthought. It has to be a repository property.

That is the right direction.

Do not trust the diff because you like the model.

Trust the diff because it survived the same boundary every other change has to survive.

references

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

agent platforms have migrations too

Paulo Victor Leite Lima Gomes — Tue, 09 Jun 2026 00:01:52 +0000

There is a very useful moment in the life of every platform abstraction.

It is not the launch demo.

It is the migration guide.

Microsoft's refreshed public preview for hosted agents in Azure Foundry has one of those moments. The old preview hosting backend is being retired. Existing deployments on the initial backend do not move automatically. Teams that built on the earlier preview need to redeploy against the new model.

That sounds like normal preview churn, because it is. Preview platforms change. APIs move. SDKs rename things. Some early assumptions do not survive contact with actual users.

But the interesting part is not that a preview changed.

The interesting part is what changed.

The refreshed hosted-agent model has a new hosting backend, protocol libraries, identity model, management APIs, dedicated agent endpoints, and a session-based sandbox model. In other words, this is not just a wrapper around a model call getting a new package name. It is infrastructure.

Agent platforms are becoming real platforms, and real platforms have migrations.

preview is not a contract

I do not think Microsoft did anything especially surprising here.

If you deploy production-critical work on a public preview, you are accepting movement. That is the deal. Sometimes the movement is small. Sometimes the thing you built against turns into scaffolding for the thing that comes next.

The problem is that AI tooling encourages people to forget this.

The marketing surface says agent. The operational surface says runtime, identity, storage, isolation, protocols, lifecycle, files, sessions, and endpoints.

Those are very different categories of risk.

A chatbot prompt can be rewritten in an afternoon. A hosted agent wired into internal workflows, private tools, project data, authentication, audit logs, and user-facing automation becomes part of the system. When the hosting model changes, you are not only changing a library import. You are revisiting trust boundaries.

That is why migration guides are more honest than launch posts.

Launch posts tell you what the platform wants to become.

Migration guides tell you what the platform actually is.

the identity change is the tell

The most important line in this kind of migration is usually the identity line.

In the refreshed Foundry hosted-agent preview, each agent gets its own Entra identity at creation time, replacing the older shared project managed identity model. That is not a cosmetic change. It changes how access is granted, reviewed, debugged, and revoked.

This is exactly where agent platforms stop being toys.

If an agent can call tools, read files, reach services, write state, and keep a session alive across turns, then "what identity does it use?" is not an implementation detail. It is the control plane.

Shared identity is convenient early. It makes demos easier. It reduces setup friction. It lets the platform feel simple.

Dedicated identity is where the abstraction starts admitting that agents are actors.

They need least privilege. They need resource-specific access. They need ownership. They need audit trails that answer "which agent did this?" instead of "something under the project identity did this."

This is the same story we already saw with workloads, services, CI jobs, and Kubernetes controllers. At the beginning, everything runs with the big credential because getting started matters. Later, after the first few uncomfortable questions, the platform grows more precise identity boundaries.

AI agents are speedrunning that history.

protocols are product boundaries

Another useful signal is the move from framework-specific adapters toward protocol libraries.

Framework adapters are great for adoption. If you are using LangGraph, Agent Framework, Semantic Kernel, or something custom, the platform can meet you where you are. That is a good on-ramp.

But adapters are not always a durable platform boundary.

Protocols are.

Foundry's refreshed model talks about Responses, Invocations, Activity, and A2A protocols. A single agent can expose multiple protocols. Dedicated endpoints now matter more. Management APIs cover the lifecycle more completely.

This is the boring part that matters.

If agents are going to be called by portals, webhooks, schedulers, internal tools, other agents, customer workflows, and maybe boring old scripts, the stable contract cannot be "whatever this framework adapter happened to expose in April."

The stable contract has to be the protocol.

This is also where teams should slow down and think.

When you choose an agent platform, you are not only choosing a model host. You are choosing the shape of invocation. You are choosing how sessions are represented. You are choosing how files move in and out. You are choosing how cancellation works. You are choosing where tool access lives. You are choosing whether your workflow is portable enough to survive the next platform refresh.

The model is the least sticky part.

The runtime contract is the sticky part.

sessions are state, and state is where platforms get serious

The refreshed preview also introduces a session-based sandbox model, with a persistent home directory and file storage across turns and idle periods.

That sounds convenient. It is convenient.

It is also state.

State is where simple agent demos become production systems.

A stateless model call is easy to reason about. Input goes in. Output comes out. You log the request, maybe store the response, and move on.

A session-based agent is different. It can accumulate files. It can remember working context. It can do multi-turn work in an environment that has continuity. The platform can provision compute on demand and deprovision it after inactivity, but the session can still matter.

That creates better user experiences. It also creates better failure modes.

What happens when a session gets too large? What is retained? Who can inspect it? How does a user delete it? Does a later turn depend on a file written by an earlier one? Can the same agent handle concurrent work safely? Can a sensitive artifact survive longer than intended because it lives in the wrong sandbox path?

None of these questions are exotic. They are the normal questions we ask about stateful systems.

The point is that agent platforms do not exempt us from those questions. They just package them in a newer interface.

the migration is the architecture review

If your team built on the old hosted-agent preview, the practical work is obvious enough: update packages, change entry points, move to the new protocol libraries, update SDK and CLI calls, grant access to the dedicated agent identity, redeploy, verify the version is active, and test real workflows.

But I would not treat that as a checklist only.

I would treat it as an architecture review.

Ask what the old design assumed:

Did the agent rely on broad project-level identity?
Did any workflow assume a shared project endpoint?
Were tools configured as deployment-time metadata when they now belong behind runtime MCP access?
Did user sessions have implicit state that nobody documented?
Are logs and audits good enough to explain agent behavior after the migration?
Can the agent be redeployed without losing important operational context?

This is the useful pain of platform churn. It exposes which parts of your system were accidental.

Some teams will discover they only had a demo. Fine. Migrate it quickly and move on.

Other teams will discover they already have production dependency on an agent runtime they did not really model as production infrastructure. That is the more interesting case.

build agents like the platform will change

The lesson is not "avoid previews forever."

That would be too easy, and also unrealistic. The agent space is moving quickly. If you wait for every surface to become boring, you will learn late.

The lesson is to keep your own contracts small.

Put your domain logic somewhere you control. Keep tool definitions explicit. Treat platform sessions as useful runtime state, not as your only system of record. Do not let authorization live only in the agent instructions. Keep invocation boundaries narrow enough that another host could call the same workflow later. Write down which resources the agent identity needs and why.

Most importantly, separate the agent's job from the platform's job.

The agent's job is to reason, call tools, and produce useful work.

The platform's job is to provide identity, isolation, lifecycle, protocols, files, observability, and policy.

When those boundaries blur, every platform change becomes a product rewrite.

When they are clear, a migration is still annoying, but it is survivable.

this is what maturity looks like

I expect more of this, not less.

Agent platforms will keep changing because the industry is still discovering the right runtime shape. We will see more dedicated identities, more protocol work, more sandbox models, more managed tool registries, more audit surfaces, more session APIs, and more lifecycle controls.

That is not a failure of the agent idea.

That is the agent idea becoming infrastructure.

Infrastructure has versions. Infrastructure has deprecations. Infrastructure has migration guides that ruin your morning and improve your architecture if you read them carefully.

The teams that treat agents as magic assistants will experience this as chaos.

The teams that treat agents as workloads will recognize the pattern.

Your agent platform is not only a place where prompts run. It is a runtime with identity, state, isolation, protocols, and operational contracts.

And runtimes have migrations.

references

Microsoft Learn: Migrate hosted agents to the refreshed public preview

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

permission prompts are not an agent security strategy

Paulo Victor Leite Lima Gomes — Mon, 08 Jun 2026 00:01:44 +0000

Docker published a practical guide last week on securing AI agents, and one sentence in it should be printed on a sticker for every engineering team adopting coding agents:

Permission prompts are not a security strategy.

That is not the whole guide, obviously. Docker talks about isolation, tool access, identity, credentials, runtime monitoring, MCP provenance, and multi-agent trust boundaries. Good. Those are the grown-up topics.

But the permission prompt line is the one that stuck with me, because it names a habit I keep seeing in agent products and internal demos.

This feels safe because a human is technically in the loop. It also feels familiar because developers already approve things all day: browser permissions, OAuth scopes, package installs, CI reruns, deploy buttons, cloud console warnings, and the occasional horrifying Terraform plan.

The problem is that prompts are usually a speed bump, not a boundary.

prompts train people to click yes

Security controls that depend on constant human attention tend to decay into theater.

Not because developers are careless. Because the workflow teaches them that approval is the price of progress.

If an agent asks for permission twenty times during a coding task, the first prompt might get real scrutiny. The second still gets a glance. By the tenth, the developer is reading for whether the action looks vaguely aligned with the task. By the twentieth, the developer is clicking approve because the alternative is babysitting a machine that was supposed to save time.

This is not a character flaw. It is interface design.

Agents make this worse because the sequence is dynamic. A coding agent may need to inspect files, install packages, run tests, generate migrations, call an MCP server, open documentation, and retry after a failure. Each step can be individually reasonable. The risky thing is the chain.

Approving one command at a time does not mean the whole workflow is safe. It just means the danger has been sliced into small enough pieces that each piece looks acceptable.

the agent needs a sandbox, not a chaperone

The better model is to give the agent autonomy inside a disposable boundary.

That boundary can be a container, a microVM, a remote development environment, or some other sandbox. The implementation matters, but the shape matters more: the agent gets enough room to do useful work, and the host machine does not become part of the blast radius.

This is why I like the container framing for agents. Not because containers are magic security dust. They are not. But because they force better questions: what filesystem can the agent see, what network can it reach, which credentials are present, and what happens when the environment is destroyed?

A prompt asks a tired human to make a local judgment. A sandbox makes the dangerous default impossible or at least contained.

If the agent needs to run tests or install packages, fine. But do that in an environment where the agent cannot casually read ~/.ssh, scrape unrelated repositories, phone home to arbitrary domains, or inherit a developer's entire cloud identity because that token happened to be in the shell.

That is the difference between supervising a risky process and designing a system where the risky process has less to break.

tool access is the real permission system

The next weak spot is tool access.

Most agent demos treat tools as capability candy. Add GitHub, Slack, Jira, docs, the database, the deployment system, a browser, and the internal MCP server someone wrote last month. The agent becomes more useful, the demo gets better, and the trust boundary quietly expands.

This is where permission prompts are especially misleading.

The important question is not whether the agent asked before using a tool. It is whether that tool should have been available for this task at all.

A frontend refactor agent does not need production database access. A dependency update agent does not need customer transcripts. A docs summarizer does not need deploy permissions. A local coding assistant probably does not need arbitrary internet access while reading private code.

This sounds obvious until you look at how teams wire tools. The easiest integration model is "give the agent everything and rely on the model to choose wisely." That is not a permission model. That is wishful thinking with JSON schemas.

Tool access should be scoped by task, environment, repository, data classification, and identity. Ideally, a gateway enforces that policy consistently instead of leaving every agent runtime to invent its own rules.

MCP makes this more urgent, not less. It standardizes how agents connect to tools, which means tool descriptions, server provenance, and tool behavior become part of the security surface. A malicious or sloppy tool is not just bad code. It is an instruction source the agent may trust.

If you would not install a random GitHub App across your production organization, do not casually hand the equivalent MCP server to every coding agent.

agents need their own identities

One of the fastest ways to make agent security unmanageable is to run agents as the developer. It is convenient. It also makes the audit story terrible.

If the agent uses my token, every action looks like me. If it pushes a branch, calls an API, reads a document, opens a ticket, or touches infrastructure, the system records Paulo did it. Maybe I asked the agent to do it. Maybe a prompt injection steered it. Maybe a tool description was poisoned. The logs do not know.

Service accounts exist because we learned this lesson already. Automated systems need identities that are scoped, auditable, revocable, and understandable. Agents are automated systems. They should have their own identities.

Not one universal "ai-agent" account with god permissions. Real identities with purpose: this repo migration agent, this incident triage agent, this documentation agent. Each one should have the minimum useful access for the job and a clear owner.

Short-lived credentials help. Runtime secret injection helps. Logs that connect the human request, agent identity, tool call, and result help even more.

The point is not to remove humans from accountability. The point is to make the machine actor visible enough that accountability means something.

what i would actually do

If a team asked me how to start securing coding agents, I would not begin with a giant AI governance committee. I would start with four defaults.

First, agents run in disposable environments. No direct host access unless there is a specific reason. No accidental inheritance of local secrets.

Second, network access is denied by default and allowlisted by task. Package registries, docs, and internal APIs should be explicit.

Third, tools are granted per workflow. Do not preload every MCP server because it might be useful someday. Useful someday is how access sprawl becomes normal.

Fourth, every agent action worth caring about is logged with enough context to explain it later: tool, parameters, identity, policy, outcome. Not because auditors are fun, but because production systems deserve evidence. Prompts cannot give you that memory after an incident.

Permission prompts can still exist. Sometimes they are useful. A prompt before deleting files is fine. A prompt before spending money is fine. A prompt before pushing a branch is fine.

But prompts should be the last-mile confirmation for unusual actions, not the main wall between the agent and the rest of your environment.

the punchline

Agents are becoming useful because they can act without asking us about every tiny step.

That is also why "just ask the human" is such a weak security model.

If the agent needs a chaperone for every action, it is not autonomous enough to deliver the workflow. If the agent can act autonomously, then the security model has to live in the environment: sandboxing, scoped tools, dedicated identities, network policy, credential hygiene, and logs.

The industry is slowly rediscovering an old systems lesson. You do not secure dangerous work by hoping every operator makes perfect decisions under interruption. You secure it by shaping the room where the work happens.

So yes, keep the prompt for the weird command.

But build the boundary first.

references

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

enterprise context is becoming the new ai platform lock-in

Paulo Victor Leite Lima Gomes — Sun, 07 Jun 2026 00:01:45 +0000

Microsoft Build 2026 had plenty of normal launch noise: more agents, more Copilot surfaces, more model choice, more reasons to pretend your backlog is about to become self-aware.

The part I keep coming back to is Microsoft IQ.

Not because the name is great. It sounds like a dashboard metric invented in a meeting with too much coffee.

But the shape of the product is important. Microsoft is turning organizational context into a platform layer for agents: Work IQ for Microsoft 365 signals, Fabric IQ for business data, Foundry IQ for application and agent context, and Web IQ for fresh web grounding. Work IQ APIs are scheduled for general availability on June 16, and the licensing page says API usage will be billed through Copilot Credits.

That is the real announcement.

The enterprise AI platform is no longer only the model. It is the context layer around the model.

And context is sticky.

the model is getting easier to swap

For the last two years, a lot of AI strategy sounded like model procurement.

Which model is best? Which provider has the longest context window? Which benchmark should we trust? Which one is cheapest for summarization? Which one can write better React code? Which one is allowed to see customer data?

Those questions still matter, but they are becoming less decisive.

The big platforms are all moving toward model routing. Microsoft talks openly about model diversity across OpenAI, Anthropic, its own MAI models, and other providers. GitHub and cloud platforms are also getting more comfortable with the idea that different agents may use different models for different work.

That is the sensible direction. A company should not bet its whole engineering workflow on a single model forever. Models improve, prices change, latency changes, risk profiles change, and some tasks simply need different tradeoffs.

But if the model becomes easier to swap, the durable lock-in moves somewhere else.

It moves to the layer that knows the company.

context is where the enterprise lives

Enterprise software is mostly local truth.

The architecture diagram is useful, but the real rule is in the migration note. The roadmap says one thing, but the customer escalation thread says another. The public API contract is in docs, but the important exception is buried in a pull request from 2023. The compliance requirement is in a policy document nobody reads until the audit week. The team decision happened in a meeting, then got half-summarized in Teams, then became a Jira ticket with the interesting sentence removed.

This is why generic agents hit a wall inside real organizations.

They can write code. They can explain APIs. They can search the web. They can be impressive in a clean repository with a good prompt.

But most useful enterprise work depends on knowing who decided what, which system owns which behavior, what the organization is allowed to do, and where the weird exceptions live.

Microsoft IQ is interesting because it goes straight at that problem. The official framing is a unified intelligence layer where agents and Copilot interactions are grounded in a shared understanding of the organization. Work IQ exposes Microsoft 365 context while preserving permissions and governance controls. Web IQ offers MCP-native grounding for external knowledge.

That is not just better retrieval.

That is the vendor saying: your agents should think through our map of your company.

this is useful and uncomfortable

I do not want to pretend this is bad technology.

If your company already lives in Microsoft 365, a context layer that understands mail, calendar, Teams, SharePoint, OneDrive, documents, organizational relationships, and existing permissions is genuinely useful.

An agent helping with a project should know the meeting where the decision happened. It should know the file the finance team treats as the source of truth. It should respect the same access controls a human employee has. It should not ask every team to rebuild enterprise search from scratch just so a model can answer "what is the current plan for this migration?"

That is the good version.

The uncomfortable version is that context is not portable in the same way a model endpoint is portable.

Once your agents depend on Work IQ semantics, Microsoft 365 permissions, Copilot Credits, Fabric ontologies, admin controls, MCP tools, and whatever ranking logic decides which internal fact matters, you have built more than an app. You have built on a vendor's interpretation of your organization.

That may be worth it.

But it is still lock-in.

lock-in is not always a trap

Engineers sometimes talk about lock-in as if it is automatically a moral failure.

That is too simplistic.

Every useful abstraction creates some lock-in. Postgres locks you into Postgres behavior. Kubernetes locks you into Kubernetes concepts. Stripe locks you into Stripe's payment model. GitHub locks you into GitHub's pull request workflow. The question is not "is there lock-in?" The question is whether the value is worth the exit cost.

For enterprise context platforms, the exit cost may be higher than teams expect.

Moving from one LLM API to another is annoying, but manageable if you planned for it. Moving from one vector store to another is also annoying, but at least the data shape is somewhat visible.

Moving away from a context layer that has become the nervous system for agents is harder.

What exactly do you export? Documents, yes. Calendar events, yes. Messages, maybe. Permission models, organizational graphs, ranking behavior, implicit relationships, access checks, tool definitions, skills, policies, and usage history? That is where it gets messy.

The most valuable part of the system is not only the raw data. It is how the platform turns the raw data into usable context at runtime.

That runtime behavior is hard to reproduce.

context governance becomes platform work

The practical question is not whether companies should use Microsoft IQ. Many will, and for good reasons.

The practical question is who owns the context layer.

If agents are going to reason over company memory, then context cannot be treated like a magic backend feature. It needs platform ownership.

Someone has to answer boring questions:

Which data sources are allowed to ground agents?
Which agents can use Work IQ, Web IQ, Fabric IQ, or custom MCP servers?
How are permissions inherited and audited?
What happens when an agent cites stale context?
Which teams can publish tools or skills into the agent environment?
How is usage billed, budgeted, and explained?
What is the fallback path if the context provider is unavailable?
How do you test whether the retrieved context was good enough?

Those questions sound operational because they are.

The mistake would be letting every team wire agents directly into whatever context source is easiest, then discovering a year later that nobody can describe which agents know what.

That is how "AI adoption" becomes another enterprise archaeology project.

microsoft is not the only one doing this

Microsoft is just the clearest example this week.

AWS is packaging agent tooling with IAM, CloudTrail, CloudWatch, managed MCP, docs retrieval, and sandboxing. GitHub is exposing cloud-agent configuration through APIs. Docker is hardening images and MCP servers. Everyone is converging on the same truth: agents need governed context, tools, permissions, logs, and runtime boundaries.

The model is the flashy part.

The platform is the part enterprises actually buy.

This is also why "model-agnostic" claims need careful reading. Web IQ being MCP-native and model-agnostic is useful. It means you are not necessarily locked into one inference provider. But a model-agnostic context layer can still be a context lock-in.

You may be able to swap the brain.

You may not be able to swap the memory.

what i would do before standardizing

If I were evaluating this inside a real company, I would not start with a grand AI architecture diagram.

I would start with one workflow where context is obviously the bottleneck.

Maybe support escalation summaries. Maybe engineering design reviews. Maybe compliance-heavy product changes. Maybe internal developer onboarding. Pick something where the agent needs real organizational memory, not just a web search and a codebase.

Then measure the unglamorous stuff.

Did the agent find the right source documents? Did it respect permissions? Did it cite useful evidence? Did it miss important context? Did it retrieve too much irrelevant noise? Did humans trust the answer more, or did they spend the same amount of time verifying it? What did the workflow cost in Copilot Credits or equivalent usage units?

Most importantly: document the dependency you are creating.

Which APIs are now in the critical path? Which data sources matter? Which admin settings define the security boundary? Which vendor-specific semantics would be painful to replace?

That is not anti-vendor paranoia. It is basic engineering hygiene.

the punchline

Microsoft IQ is a good signal for where enterprise AI is going.

The winning platforms will not just offer better models. They will offer better access to the messy, permissioned, constantly changing context inside the company.

That is useful. It is also where the next generation of lock-in will live.

The old cloud lock-in was compute, storage, databases, and deployment pipelines. The new AI lock-in is organizational memory, tool permissions, grounding behavior, and the agent runtime that makes those things usable.

So yes, use the context layer. The generic assistant that does not understand the organization will be too shallow for serious work.

But do not treat context as a free ingredient.

Context is infrastructure now.

And once your agents depend on it, it deserves the same boring attention as every other piece of infrastructure: ownership, observability, cost controls, security boundaries, portability plans, and a clear understanding of what happens when it lies.

references

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

codex on AWS makes agents a cloud workload

Paulo Victor Leite Lima Gomes — Sat, 06 Jun 2026 00:02:44 +0000

OpenAI putting Codex and frontier models on AWS is easy to read as a distribution story.

One more cloud. One more enterprise channel. One more place where procurement can buy the shiny thing without a special exception.

That reading is not wrong, exactly. It is just too small.

The interesting part is not that Codex can now run closer to AWS customers. The interesting part is that a coding agent is no longer just an IDE feature, a CLI, or a chat window pointed at a repository.

It is becoming a cloud workload.

That changes the shape of the problem. Once an agent can read code, open pull requests, call tools, reach cloud APIs, inspect logs, and maybe modify infrastructure, the hard questions are not "which model is smartest?" The hard questions are the old boring platform questions:

Which identity is the agent using?
Which network can it reach?
Which secrets can it see?
Who approved the action?
Where is the audit trail?
What happens when the bill spikes?
Who owns the failure when the generated change breaks production?

Welcome back to software engineering.

distribution is governance in disguise

OpenAI's announcement says Codex on Amazon Bedrock brings the software engineering agent into AWS, using the security, governance, procurement, billing, and operational workflows enterprises already have.

That sentence is doing a lot of work.

For individual developers, a coding agent feels like a productivity tool. You give it a task, it changes files, you review the diff. The boundary is psychological and local: do I trust this thing enough to accept the patch?

For a company, that boundary is nowhere near enough.

An enterprise does not merely buy "a better coder." It buys an execution surface. The agent needs credentials. It needs access to source code. It may need package registries, internal docs, issue trackers, cloud consoles, observability systems, CI logs, and deployment pipelines. Every one of those integrations turns the agent from a helpful assistant into an actor inside the company's control plane.

That is why AWS availability matters.

Not because every company loves AWS so much that all AI must live there. Because many companies already have the boring machinery around AWS: IAM, CloudTrail, VPC boundaries, procurement, budgets, policy exceptions, account structures, incident processes, and security review muscle memory.

Putting Codex into that world is not just about latency or convenience. It is about letting the agent inherit an operating model the enterprise already understands.

the multi-cloud part is not optional

There is another uncomfortable implication here: agent infrastructure is going multi-cloud by default.

A normal engineering organization already lives across several control planes. Source code may be in GitHub. Identity may be in Okta or Entra. Production might be on AWS. Developer productivity might be tied to Microsoft. Some AI contracts may run through OpenAI directly. Some models may come through Bedrock. Some teams will still run local agents on laptops because that is where the work actually happens.

Nobody is going to cleanly centralize this.

The agent will cross boundaries because the work crosses boundaries.

It will read a ticket in one system, search docs in another, patch code in a repo, run tests in a sandbox, query logs in the cloud, and ask for a human review in a pull request. If you are lucky, each step has a useful audit trail. If you are unlucky, the agent becomes a very confident intern with five browser tabs, broad credentials, and no memory of why it clicked the thing it clicked.

This is the real platform problem.

The winning agent stack is not the one with the nicest chat box. It is the one that can carry identity, authorization, policy, observability, cost accounting, and review semantics across the whole workflow.

That is much harder than adding another model picker.

coding agents need platform contracts

I keep coming back to the same pattern: AI tools become serious when they stop pretending the model is the product.

For coding agents, the product is the system around the model.

The model can propose a fix. Fine. But a production-grade coding agent needs a contract for how that fix moves through the organization.

It needs scoped repository access, not "here is the company GitHub token." It needs ephemeral sandboxes that can be killed, inspected, and reproduced. It needs tool permissions that are narrow enough to reason about. It needs separate identities for reading logs, opening pull requests, and changing infrastructure. It needs policy gates before dangerous actions. It needs cost budgets. It needs provenance on generated code. It needs a way to explain what context it used.

This sounds boring because it is boring.

It is also the difference between a demo and something a serious company can leave running.

The more capable agents become, the less acceptable it is to treat them as fancy autocomplete. Autocomplete suggests text. Agents act. Once a system acts, you need the boring nouns: identity, policy, audit, isolation, rollback.

AWS is packaging the path, not just the model

AWS is not being subtle about this either.

Agent Toolkit for AWS is framed around managed MCP, AWS-specific skills, IAM guardrails, CloudTrail and CloudWatch observability, and sandboxed execution. AWS Transform agents are being pushed into developer tools like Kiro, Cursor, Claude, and Codex. Bedrock AgentCore is part of the same story.

The cloud providers have noticed that generic model knowledge is not enough.

An agent that knows AWS from public documentation is useful until it confidently wires together a production footgun. Cloud knowledge changes. Services have edge cases. Account structures vary. Security expectations are local. The right answer often depends on company policy, not Stack Overflow consensus.

So the cloud providers are turning best practices into runtime inputs.

That is a big shift. Cloud guidance used to live in docs, templates, reference architectures, and the heads of staff engineers who had been burned before. Now it is being packaged as agent context, tool definitions, policy constraints, and managed execution environments.

This is not documentation becoming nicer.

This is documentation becoming executable.

what i would watch

If I were running platform engineering in a company adopting coding agents, I would not start by arguing about which model is "best."

I would start with the control plane.

Can every agent action be tied to a durable identity? Can I tell the difference between Paulo using an agent and the agent acting autonomously after Paulo assigned a task? Can I restrict tools by repository, environment, account, and risk level? Can I see the prompt, context sources, commands, diffs, test results, and approvals that led to a change? Can I cap spend per team? Can I revoke access without breaking every developer's local setup?

Those questions sound unglamorous. That is usually a sign they are close to the real work.

I would also watch for a new kind of lock-in: operational memory. Policies, agent skills, tool contracts, approval flows, and audit records can become just as sticky as APIs and managed services.

That does not mean "avoid managed agent platforms." Managed platforms are often the right choice. It means teams should be explicit about what they are adopting. Are they buying model access, or are they buying an operating system for agentic work?

Those are very different commitments.

the punchline

Codex on AWS is not just OpenAI adding another distribution channel.

It is a signal that coding agents are moving from developer tools into cloud infrastructure.

That move is probably inevitable. The work agents need to do already crosses cloud boundaries, source control boundaries, identity boundaries, and organizational boundaries. Keeping agents trapped inside a chat box was never going to be the final shape.

But the moment agents become workloads, the conversation changes.

The model still matters. Of course it does. Better reasoning, better code generation, better tool use, and better reliability all matter.

They are not enough.

The serious question is whether the agent can operate inside the same governance envelope as the rest of the company. Identity. Audit. Network policy. Cost. Review. Rollback. Ownership.

The boring stuff again.

That is where the next phase of coding agents will be won or lost.

references

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

the developer laptop is the first production environment for agents

Paulo Victor Leite Lima Gomes — Fri, 05 Jun 2026 00:02:47 +0000

Docker published a post this week about securing AI agents, and the most interesting part was not really Docker.

The post makes the now-familiar argument that agents need execution isolation, tool access control, identity and credential management, and runtime monitoring. It also says the quiet part clearly: permission prompts are not enough.

That should be obvious.

It is not obvious enough.

Most of the discussion around coding agents still treats the developer machine as a convenient place where the magic happens. The agent runs in your editor. It sees the repository. It can call tools. It can read logs, run tests, install packages, open browsers, hit APIs, and sometimes push code. If it asks nicely before doing the scary thing, we call that security.

This is backwards.

The developer laptop is becoming the first production environment for agents.

local does not mean low risk

We have a bad habit of treating local development as safer than production because it is smaller.

Production has customer data, uptime guarantees, compliance rules, and dashboards. The laptop has a half-finished branch, a terminal, and a human nearby, so we relax.

But a modern developer machine is a wonderful target.

It has source code, cloud credentials, package manager tokens, SSH keys, browser sessions, local databases full of copied production-shaped data, and access to staging systems that are often less locked down than production. It also has build scripts that can run arbitrary code.

Now put an agent on that machine and give it the same tool surface a senior engineer uses.

That is not a chatbot anymore.

That is an automation actor inside one of the most privileged environments in the company.

permission prompts are a user interface, not a boundary

The obvious answer is to ask the human for permission.

Can I run this command?

Can I edit this file?

Can I access the network?

Can I install this dependency?

Prompts are useful. I like them. They slow things down just enough that I sometimes notice the agent is about to do something silly.

But prompts are not a security model.

They depend on the human understanding the full consequence of an action at the moment the prompt appears. That is a lot to ask when the command is npm install, the dependency graph is 800 packages deep, and the agent presents it as the next obvious step.

The prompt says "run tests."

The test runner executes lifecycle scripts.

The lifecycle script reads an environment variable.

The environment variable contains a token that can deploy to staging.

The human clicked yes because running tests is normal.

This is why runtime containment matters. A useful prompt can ask for intent. A real boundary limits blast radius when intent and consequence drift apart.

agents need less trust than developers

There is an uncomfortable point here: agents should usually have less authority than the developer supervising them.

That sounds inefficient. It is also how every other automation system eventually grows up.

We do not give CI the CEO's laptop because it needs to run tests. We do not give a GitHub Action every cloud permission because one deployment step needs one credential. We do not let a build worker freely write to every repository because it might be convenient someday.

We scope automation because automation is fast, literal, and bad at knowing when the surrounding context has changed.

Coding agents are the same category of problem, just with a more charming interface.

An agent editing a README does not need AWS credentials. An agent refactoring a parser does not need the network by default. An agent generating a migration should not be able to apply it to a shared database unless that is an explicit, isolated workflow. An agent investigating a bug may need redacted logs through a narrow tool, not a shell with access to everything the human can reach.

The useful default is not "this is my assistant, so it inherits my machine."

The useful default is "this is an automation process, so it gets the smallest workspace and tool set that can complete the task."

the old sandbox conversation is back

This is the part I find funny in a tired way.

We spent years building containers, microVMs, CI isolation, network policies, service accounts, secret managers, and audit trails. Then AI coding tools arrived and a lot of demos quietly stepped around those lessons because the local magic was too good to interrupt.

Now we are rediscovering the same architecture.

Run the agent in an isolated workspace. Mount only the files it needs. Give it an explicit network policy. Pass credentials through scoped tools instead of ambient environment variables. Separate read-only inspection from write-capable actions. Keep enough evidence that a human reviewer can reconstruct the path from prompt to diff.

None of this is exotic. It is just platform engineering applied to the developer machine.

Docker talking about agent isolation is interesting because Docker already won the mental model for "this process gets a filesystem, a network shape, and a boundary." MicroVMs push the boundary further. Operating system features will keep moving in the same direction. Microsoft is already talking about agent runtime boundaries at the platform layer.

The direction is clear: agent security is moving below the app and editor.

It has to.

the laptop is where policy gets tested first

The enterprise version of this conversation will eventually become very formal.

There will be agent identities, audit APIs, policy engines, approved tool catalogs, model routing rules, and budget controls. There will be dashboards showing which agent touched which repo under which human supervisor.

Before that, there is a laptop.

That is where the first bad patterns appear:

agents reading files they did not need
agents installing packages from the public internet without review
agents using broad human credentials because scoped credentials are annoying
agents producing diffs without enough execution evidence
agents running commands whose side effects nobody inspected
agents mixing trusted project state with untrusted generated artifacts

Those are not hypothetical enterprise governance problems. They happen during ordinary development when the tool is good enough to keep using and not mature enough to fully trust.

The laptop is where the policy either becomes ergonomic or dies.

If the secure path is too slow, developers will route around it. If the isolated environment cannot run the project, they will turn it off. If credential scoping breaks every useful workflow, the broad token comes back. If the audit trail is unreadable, reviewers will ignore it.

Agent security has to be boring, local, and fast enough that people leave it on.

what i would do now

If I were responsible for rolling coding agents into an engineering team, I would start with local containment before writing a grand AI governance document.

First, separate workspaces. The agent should operate in a copy, branch, container, or sandbox where accidental writes are cheap. The human can review and promote the result.

Second, make network access explicit. Many coding tasks do not need the internet. The ones that do should say why. Package installation should be treated as a supply-chain event, not as background noise.

Third, remove ambient credentials. If the agent needs to call a service, give it a scoped tool or short-lived credential for that task. Do not let it inherit every token the developer happened to have in their shell.

Fourth, preserve evidence. Commands, outputs, files changed, tests run, and external calls should be visible in a reviewable trail. The human reviewer should not have to trust the agent's summary of what happened.

Fifth, make the safe path pleasant. This is the boring product work. If the sandbox takes five minutes to start, nobody will use it. If the policy requires twenty approvals for a typo fix, people will disable it. Security that cannot survive daily development is a memo, not a system.

the punchline

Local coding agents feel personal because they sit in the editor and speak in first person.

Operationally, they are automation systems running inside a privileged environment.

That distinction matters.

The developer laptop has source code, credentials, build tools, staging access, and a human who is busy trying to ship. It is not a toy environment just because it is local. For agents, it is the first production environment, and it deserves production-shaped boundaries.

Permission prompts are useful. They are not enough.

The real product is containment, identity, scoped tools, audit trails, and a workflow developers will actually keep turned on.

Welcome back to software engineering. The agent is new. The security problem is not.

references

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

agent canvases are the end of chat-only coding tools

Paulo Victor Leite Lima Gomes — Thu, 04 Jun 2026 00:03:22 +0000

GitHub added something to the Copilot app this week that sounds like a UI feature and feels like a category shift.

Canvases.

The obvious read is that GitHub is making the Copilot app nicer. More visual. More desktop-app-like. Less like typing into a narrow chat box and hoping the agent understood the assignment.

I think that undersells it.

The interesting part is not that the app has a prettier place to show work. The interesting part is that agent work is outgrowing the transcript. Once an agent can plan, edit, browse, run a terminal, open a pull request, respond to review comments, and continue across sessions, chat becomes a very weak control surface.

Chat is good for intent.

It is bad for state.

chat was a good starting point

Chat was the right first interface for AI coding tools.

It is familiar. It is forgiving. You can be vague, then get more specific. You can ask "what do you think?" before asking for a diff. You can paste an error and let the model do the first pass at reading the stack trace.

For simple work, that is enough.

"Explain this function."

"Write a test for this edge case."

"Change this component to use the new prop."

The chat transcript is not elegant, but it works because the task is small. The human can hold the goal, the context, and the result in their head.

Long-running agent work is different.

When an agent spends thirty minutes across a branch, a browser, a terminal, a checklist, and a pull request, the transcript becomes a pile of archaeology. Somewhere in there is the plan. Somewhere else is the reason it changed direction. Somewhere else is the test failure. Somewhere else is the final diff. You can scroll. You can search. You can ask the agent to summarize itself, which is both useful and slightly absurd.

That is not a serious review surface.

work needs an object

The GitHub changelog describes canvases as bidirectional work surfaces where people and agents inspect, edit, approve, and redirect work. The examples are telling: plans, pull requests, browser sessions, terminals, release checklists, migration boards, incidents, dashboards, workflow state.

That list matters because it points at the real problem.

Agentic software work does not produce only text. It produces objects:

a plan with steps and dependencies
a diff with intent and risk
a browser session with evidence
a terminal run with commands and failures
a checklist with ownership
a pull request with review state
a deployment or migration with progress

If those objects only exist as messages in a chat, the human has to reconstruct the work every time they want to make a decision.

That is backwards.

The interface should expose the object directly. The conversation should steer the work, but the work should live somewhere inspectable.

This is the same lesson every engineering system eventually learns. Issue trackers beat hallway conversations because the issue becomes a durable object. Pull requests beat emailing patches because the change gets a review surface. CI dashboards beat "it passed on my machine" because the result is attached to a run.

Agents need the same move.

agent experience is not just developer experience with a new label

GitHub is using the phrase "agent experience" for this, and I like it more than I expected.

Developer experience is usually about helping humans move through tools with less friction: editors, CLIs, docs, APIs, tests, deployment workflows, observability. Good DX makes the human less likely to lose context or do the wrong thing accidentally.

Agent experience adds another participant.

Now the workflow has to be usable by a human and legible to an agent. The agent needs structured state it can read. The human needs visible state they can trust. The app needs to enforce which actions are allowed. The system needs to remember enough history that a future reviewer can understand what happened without treating the chat log as the source of truth.

That is not cosmetic.

It changes how we should design internal engineering workflows.

If a migration board is agent-operable, the board cannot be a vague spreadsheet with tribal rules in comments. If a release checklist is agent-operable, the checklist needs clear states, owners, evidence, and stop conditions. If a pull request is agent-operable, the agent needs to know which review comments are instructions, which are discussions, and which require human judgment before it continues.

The UI is only the visible part.

The deeper work is making engineering process structured enough that both humans and machines can participate without guessing.

transcripts hide too much

The transcript has one big virtue: it preserves the conversation.

That is also its problem.

Conversations are messy. They include false starts, corrections, half-formed ideas, jokes, clarifications, and decisions that only make sense because both participants remember what happened five minutes ago. Humans are decent at that in the moment. We are worse at it later. Agents are even more dangerous because they can turn a messy history into a confident summary that sounds cleaner than the actual work was.

For agentic coding, I do not want the final state to depend on vibes from a transcript.

I want the plan to show current status.

I want the diff to show what changed and why.

I want the terminal surface to show which commands ran and which failed.

I want the browser surface to show what was verified.

I want the PR surface to show what remains unresolved.

The chat can remain useful for steering. But review needs evidence attached to the work object, not buried in the conversation that produced it.

This matters more as agents get better. A bad agent is easy to distrust. A good agent produces polished, plausible work. The interface has to make the uncertainty visible even when the prose sounds confident.

what i would look for

If I were evaluating agent coding tools for a team, I would spend less time asking whether the chat feels magical and more time looking at the work surfaces.

Can I inspect the current plan without asking the agent to summarize itself?

Can I edit the plan directly?

Can I see which files are in scope and which files are not?

Can I tell what commands ran and from which environment?

Can I tell why the agent changed direction?

Can the final pull request preserve enough evidence for review?

Those questions are boring in the best possible way. They are the questions that show whether an AI coding tool is becoming a production tool or staying a demo interface.

The magic text box is not enough.

It never was.

It was just enough to get us started.

the punchline

Agent canvases are interesting because they admit something the industry has been circling for a while: chat is not the final interface for software agents.

Chat is a good place to express intent. It is a poor place to manage durable, inspectable, reviewable work.

Software engineering already has objects for serious collaboration: issues, branches, pull requests, CI runs, dashboards, incidents, release plans, and deployment records. Agents do not remove the need for those objects. They make them more important, because more work can now happen between human decisions.

So yes, the Copilot app getting canvases is a product update.

But the deeper signal is architectural.

Agent work needs state outside the transcript. It needs surfaces where humans can inspect and redirect, where agents can read and update structured intent, and where the system can enforce boundaries.

The future of coding tools is not everyone chatting harder.

It is workbenches where conversation, state, evidence, and review finally live in the same place.

references

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

Openclaw on the cloud, dos and don'ts

Paulo Victor Leite Lima Gomes — Wed, 03 Jun 2026 15:16:35 +0000

Running OpenClaw or Hermes in the Cloud (No Mac Mini Required)

If this is your first time setting up an always-on AI agent like OpenClaw or Hermes, you have probably seen people running them on a Mac Mini sitting on their desk. You do not need that. A cheap Linux VPS does the job just as well, costs a few euros a month, and you can rebuild it in minutes if something breaks.

This is a no-fluff, step-by-step guide to get one of them running in the cloud.

First, the myth: "I need to buy a Mac Mini"

You don't. Here is the key thing to understand:

The agent (OpenClaw or Hermes) is a lightweight gateway. It reads your messages, decides what to do, and calls tools. This part is cheap to run.
The heavy compute is the LLM inference. If you use a cloud model (Claude, GPT, Gemini, DeepSeek via API), that work happens on the provider's servers, not yours.

So a small VPS with 1-2 vCPU and 2-4 GB RAM is plenty when you point the agent at a cloud model. You only need real hardware (a Mac Mini, a GPU box, or DGX-class machines) if you insist on running the model locally for privacy. For most people starting out, cloud model + small VPS is the right call.

Step 1: Pick a cheap cloud provider

You want a basic Linux VPS. Any of these work. Prices are rough and change often, so check before you buy.

Provider	Why	Rough price
Hetzner Cloud	Cheapest decent option, EU-based (good if you are in Poland or the EU)	~€4/mo for 2 vCPU / 4 GB
Contabo	Very cheap, generous RAM, German	~€5/mo
Oracle Cloud Free Tier	Genuinely free ARM instance (4 cores / 24 GB), but signup is fiddly	Free
DigitalOcean / Vultr / Linode	Simple, reliable, good docs	~$4-6/mo
AWS Lightsail	Has a ready-made OpenClaw blueprint if you want one-click	~$5-7/mo

If you just want the cheapest reliable thing and you are in Europe, start with Hetzner. Pick Ubuntu 24.04 LTS as the OS.

Step 2: Create the server and connect

Create the VPS (Ubuntu 24.04, smallest tier with at least 2 GB RAM).
Add your SSH key during creation. Do not use password login.
SSH in:

ssh root@YOUR_SERVER_IP

Do the basic hardening before anything else:

# update
apt update && apt upgrade -y

# create a non-root user
adduser agent
usermod -aG sudo agent

# basic firewall: allow SSH only, deny the rest
ufw allow OpenSSH
ufw enable

Now log back in as agent instead of root. This matters, because these agents can run shell commands. You do not want them running as root.

Step 3a: Install OpenClaw

OpenClaw is open source (MIT, github.com/openclaw/openclaw). It runs as a background daemon and connects to your messaging apps.

Install Node.js (it is a TypeScript/Node project) and then OpenClaw following the install instructions in the repo README. The project ships an install script and runs as a systemd service on Linux.
During setup you will set a gateway auth token. Treat this like a password. Store it in an environment file, not hardcoded in your config.
Add your LLM provider key (for example, an Anthropic or OpenAI key).
Connect a messaging channel. Telegram is the easiest: create a bot with BotFather, copy the token, and paste it into the channel config.
Start the daemon and message your bot. It runs on a heartbeat (every 30 minutes by default), checking its task list and acting when needed.

Step 3b: Install Hermes (the alternative)

Hermes Agent, by Nous Research, is the other popular option. Same idea: a self-hosted agent that lives on your server, remembers things across sessions, and runs scheduled tasks. It is open source (MIT, github.com/NousResearch/hermes-agent) and supports Linux, macOS, and WSL2.

The install is famously simple, a single command that pulls in everything:

curl -fsSL https://hermes-agent.org/install.sh | sh

(Always read an install script before piping it to a shell. This is just the documented one-liner.)

Then:

Configure a model provider with hermes model. It is model-agnostic: Nous Portal, OpenRouter, Anthropic, OpenAI, Gemini, DeepSeek, or a local Ollama endpoint. You need a model with at least 64k context, which most modern hosted models have.
Connect a messaging platform (Telegram, Discord, Slack, Signal, email, or just the CLI).
Start it and talk to it.

OpenClaw vs Hermes, short version: they share the same DNA, self-hosted, messaging-driven, local data, custom skills. Hermes leans more "research lab" (built-in learning loop, skills it writes for itself, training-data tooling). OpenClaw has the larger ecosystem and more ready-made cloud blueprints. For a first setup, either is fine. Pick one and move on.

Step 4: Lock it down (do not skip this)

These agents can read your messages, run code, and call APIs with your keys. That makes them a target. There have been real, documented problems: a high-severity remote exploit, and security researchers finding tens of thousands of agent instances exposed directly to the internet with no login.

Minimum precautions:

Never expose the gateway port to the public internet. Keep it behind the firewall and reach it through SSH or a private network.
Rotate your auth token and keep it in an env file, never in a committed config.
Run as a non-root user, and sandbox tool execution so an unknown sender cannot get a free shell.
Do not install random community "skills" without reading them. Malicious skills have been used to ship info-stealers.

A note on shipclaw.io

You will probably run into shipclaw.io, a managed hosting service that promises to deploy OpenClaw or Hermes bots for you in about a minute, no server setup, no API key juggling. On the surface it sounds genuinely useful, and the "I don't want to manage a daemon" pitch is real.

Here is the catch, and why I would not put my tokens there yet. There are several similarly named domains (shipclaw.io, shipclaw.app, shipclaw.org), and the origins trace back to individual social posts rather than a clearly identifiable company. We could not find a verifiable company behind it, on LinkedIn or anywhere else, no clear team, no track record.

That matters more than usual here. The whole point of these agents is that they hold your LLM API tokens and often have shell and tool access. Handing those to a managed service means trusting the operator with the keys to your spending and your data. For an unverified provider, that trust is not earned yet.

So: interesting idea, worth watching, but until there is a real, identifiable company behind it, self-host on your own cheap VPS where you control the keys.

What it actually costs

VPS: €4-7/month (or free on Oracle's tier).
LLM usage: pay-as-you-go to whichever model provider you choose. A light personal agent is usually a few dollars a month; heavy use is more.
Hardware: €0. No Mac Mini, no GPU, nothing to buy.

That is the whole thing. Spin up a small Linux box, install OpenClaw or Hermes, point it at a cloud model, connect Telegram, lock the door, and you have an always-on agent for the price of a coffee per month.

copilot automations turn agents into scheduled infrastructure

Paulo Victor Leite Lima Gomes — Wed, 03 Jun 2026 00:04:15 +0000

GitHub keeps adding small pieces to Copilot cloud agent, and the pattern is getting harder to miss.

The latest one is scheduling and event-based automation. Copilot cloud agent can now be kicked off automatically, instead of waiting for a human to type a prompt in an editor or assign an issue.

That sounds like a feature update. It is more than that.

Once an agent can wake up on its own, inspect a repo, make changes, and open a pull request, it stops being a chat assistant. It becomes scheduled infrastructure.

It belongs in the same mental bucket as cron, CI, release bots, dependency update bots, and all the quiet automation that slowly became load-bearing because nobody wanted to do the same boring thing every Tuesday.

The difference is that this bot has judgment attached.

That is useful. It is also where the trouble starts.

agents are becoming repo actors

I wrote recently about GitHub's agent audit API being a boring feature that matters. This is the same direction, just from the other side.

First, GitHub made agents visible enough to audit. Then it made them easier to start through APIs. Now it is making them easier to run automatically.

That sequence matters. It is the shape of a product becoming infrastructure. The demo is "Copilot fixes small problems while you sleep." The production version is "we now have autonomous repository actors with schedules, permissions, cost, logs, and drift."

When something can only run after a developer manually asks for it, the risk is bounded by human attention. Someone had to decide to start the task. Someone was probably looking at the result soon after.

When something runs every night, every release, every issue label, or every failed workflow, it becomes part of the system.

You do not manage that like a clever autocomplete.

You manage it like a worker.

It needs an identity, scoped permissions, a budget, retry behavior, a place in the incident model, and a way to be paused quickly.

The phrase "AI agent" makes this feel new. The engineering shape is familiar: we are putting another actor inside the repository and giving it permission to create work.

the useful jobs are boring

I would not start with "rewrite our payment system overnight." Please do not do that.

The useful first jobs are maintenance work everyone agrees should happen:

refresh examples after an API change
update internal docs when a config file changes
prepare release notes from merged pull requests
propose small dependency migration PRs
clean up TODOs that match a narrow rule
investigate flaky tests and draft a hypothesis

The value of scheduled agents is not that they replace deep engineering work. It is that they can keep starting small pieces of work that normally die because they are annoying, low-status, and easy to postpone.

That is where I would expect real adoption: not giant autonomous projects, but steady background pressure on repository entropy.

Every repo has entropy. Docs rot. Tests get noisy. Examples drift. Labels lie. Release notes get assembled at the last minute.

If an agent can turn some of that into draft pull requests, that is useful.

But the word "draft" is doing a lot of work there.

review is the control plane

The pull request is still the right boundary.

I know that sounds boring. It is also important. A scheduled agent that opens a PR is much easier to govern than a scheduled agent that directly changes production behavior.

The PR gives you a diff, review process, status checks, branch protection, comments, and an audit trail. It gives the team a familiar place to say "this is wrong" or "this should have been three smaller changes."

That does not make the agent safe by default. It gives you a place to apply controls you already understand.

The mistake would be treating the PR as a formality because the agent is "just doing maintenance."

Maintenance work can break things. Docs changes can publish wrong information. Dependency updates can change runtime behavior. Release note automation can expose something sensitive. A flaky test investigation can delete the wrong assertion because it looked suspicious.

The right posture is boring:

branch protection still applies
required checks still apply
humans still own merges
agent-authored PRs should be labeled clearly
narrow tasks are better than vague tasks
the prompt or task definition should be inspectable

Agents do not remove the need for process. They make sloppy process louder.

cost becomes part of the architecture

There is another unromantic detail here: scheduled agents cost money.

Maybe the unit price is small. Maybe the model is cheap. Maybe the task only runs once a week. Fine. But once teams discover a useful automation, they make more of it. Then every repo wants nightly cleanup, weekly release prep, flaky test triage, dependency migration, documentation refresh, and security review help.

Suddenly AI spend is not a subscription line item. It is closer to build minutes, runner capacity, or log volume.

This is why budgets and model choice matter. A small model may be enough for routine maintenance. A more capable model may be worth it for complex migrations. Some tasks should run on every push. Others should run weekly. Some should not run automatically at all.

That is an architecture decision, not finance trivia.

If your agent task consumes compute, Actions minutes, model tokens, or reviewer time, it is part of the system cost. Treat it that way before the bill becomes the first observability dashboard anyone checks.

sandboxes are not optional

Scheduled agents also make sandboxes more important.

If an agent runs once while a developer is watching, a weak sandbox is still bad. If it runs on a schedule across many repositories, a weak sandbox becomes an organizational habit.

The agent needs a controlled environment: filesystem boundaries, network rules, tool restrictions, secret access rules, and clear defaults around what it can install or execute.

This is especially true for repository events. A schedule is predictable. Event-driven automation can be triggered by messy real-world inputs: issues, labels, PR comments, failing tests, dependency changes, maybe even content from outside contributors.

That does not mean "never automate." It means the automation has to assume hostile or simply weird input.

The old CI lesson applies: the interesting question is not whether the job can run. It is what the job can reach while it is running.

what i would do first

If I were rolling this out inside a company, I would start small and extremely specific.

One repository. One scheduled task. One narrow category of work. One clear owner.

For example: every Friday, have the agent prepare a draft release note PR from merged changes and existing labels. It should not invent product claims or merge anything. It should only produce a draft that a human edits.

Then I would measure the useful stuff:

How often was the PR useful?
How often did it require correction?
How much review time did it consume?
What did it cost?
Did it touch files outside its intended scope?
Did it produce changes the team actually merged?

That tells you more than a demo ever will.

If the first automation is useful, add another. If it is noisy, tighten the task. If it creates review burden, make it smaller or less frequent. If nobody owns it, delete it.

The bad version is a pile of abandoned scheduled agents opening low-quality pull requests into repositories nobody wants to maintain.

We already learned that lesson with alerting, dashboards, CI jobs, and dependency bots. Automation without ownership becomes background noise. AI does not change that.

the punchline

Scheduled Copilot cloud agent tasks are interesting because they make the agent less like a feature and more like infrastructure.

That is the real shift.

The repo now has another worker. It can wake up without a human prompt, inspect state, make decisions, spend money, create pull requests, and ask for review.

That can be genuinely useful. I want boring maintenance work to get cheaper. I want release prep to be less annoying.

But the useful version is not magic. It is disciplined automation.

Give the agent a narrow job. Put it in a sandbox. Make the output reviewable. Track the cost. Keep the owner visible. Delete the automation when it stops paying rent.

That is not as exciting as "agents will run engineering."

It is much closer to how engineering actually gets better.

references

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

AI code review is now a cloud workload

Paulo Victor Leite Lima Gomes — Tue, 02 Jun 2026 00:01:22 +0000

Code review used to have a very human scaling problem.

The pull request was ready. The tests were green. Then it sat there waiting for someone with enough context, enough patience, and maybe enough coffee to read it properly.

AI code review changes that queue. GitHub Copilot can review pull requests automatically, and since June 1, those reviews consume GitHub AI Credits. For private repositories, they can also consume GitHub Actions minutes while Copilot prepares the environment and analyzes the code.

This is not surprising. Models cost money. Runners cost money.

But it does make the product category much clearer.

AI code review is not merely a helpful comment bot anymore. It is a cloud workload triggered by your development process.

And cloud workloads need budgets.

the review button is now an infrastructure decision

There is a familiar progression in developer tooling.

At first, a feature feels small and local. Someone enables it. A few people try it. The cost is invisible because the usage is limited and the invoice is mixed into something larger.

Then adoption grows.

Soon, the same feature runs across hundreds of repositories, thousands of pull requests, and multiple review passes per change. A product that felt like an editor convenience becomes an operating expense.

We already learned this with CI.

The first pipeline is cheap. Then every commit runs unit tests, integration tests, security scans, preview deployments, browser tests, and half a dozen checks nobody wants to remove because nobody remembers why they were added.

The pipeline is useful. It is also a bill.

AI review is entering the same phase.

GitHub's new billing model is explicit: code review consumes AI Credits, and private repositories use Actions minutes during the analysis. Organizations can configure a default runner and apply budgets at the user level.

Those controls sound boring.

They are also the part engineering leaders should care about.

review everything is not a strategy

It is tempting to enable AI review everywhere.

Why not? More review sounds better than less review. If the bot catches one security bug, one missing test, or one questionable API change, the entire month might pay for itself.

That is probably true in some teams.

It does not follow that every review is equally valuable.

A ten-line dependency bump and a large authentication refactor should not necessarily receive the same treatment. A generated documentation change may not need an AI reviewer. A risky database migration probably deserves more than one automated pass and a quick human approval.

Once reviews are metered, the policy questions become unavoidable:

Which repositories should request AI review by default?
Which pull requests should trigger it automatically?
Should generated changes receive the same review budget as human-written changes?
How many review rounds are useful before the comments become noise?
What runner size is actually necessary for each repository?
Which teams are spending more because their codebase is harder to analyze?

These are not finance-only questions.

They are architecture and engineering-management questions expressed through a bill.

cost attribution is a useful forcing function

I do not think metering is automatically bad.

Free-looking infrastructure has a way of hiding bad habits. A budget can force a team to decide what it actually values.

If one repository uses far more AI review credits and runner minutes than another, there may be a good reason. Maybe it is a critical service. Maybe the diffs are complex. Maybe the team is using the reviewer as an extra security layer.

Or maybe every tiny pull request is triggering an expensive workflow because nobody looked at the defaults.

The useful outcome is not minimizing the bill at all costs. The useful outcome is understanding what the bill represents.

CI minutes can tell you that your tests are too slow, too broad, or too flaky. Cloud spend can tell you that an architecture is chatty, over-provisioned, or poorly cached. AI review spend can reveal that your workflow is asking a model to examine a lot of low-value changes.

Cost is architecture feedback.

the other bill is reviewer attention

There is a second cost that will not appear on the GitHub invoice.

Every AI review comment asks a human to spend attention.

Some comments will be useful. Some will be technically correct but irrelevant. Some will identify a real concern without understanding why the code looks strange. Some will confidently suggest a cleaner implementation that quietly breaks an ugly but important edge case.

That means the cheapest AI review is not always the best one.

A review that costs a few credits but creates ten minutes of distraction for two engineers is expensive in a different way. Multiply that across a large organization and the bigger problem may be signal quality, not model usage.

This is why "number of AI review comments" is a terrible success metric.

The metrics I would want are more practical:

How often does an AI comment lead to a code change?
Which categories of comments are consistently useful?
How often are comments dismissed as noise?
Does AI review reduce human review time or add another review queue?
Does it catch defects that tests and static analysis missed?
Are teams starting to rubber-stamp reviews because a bot already looked at the diff?

The goal is not more comments.

The goal is better changes reaching production with less wasted attention.

keep humans in the uncomfortable parts

AI review is good at broad, patient inspection.

It does not get bored reading the fifth similar file. It can notice missing error handling, suspicious patterns, inconsistent tests, and changes that deserve a second look. It can give a pull request author feedback before a human reviewer arrives.

That is useful.

But the highest-value review questions are usually uncomfortable and contextual:

Is this the right change for the system?
Does the abstraction make future incidents easier or harder to debug?
Are we preserving an API contract that is not documented anywhere?
Is the migration plan realistic under production load?
Is this complexity necessary, or did we create it because the generated code looked plausible?

Those questions need judgment.

The AI reviewer can help surface evidence. It should not become a reason to skip the conversation.

what i would do this week

If your organization uses Copilot code review, I would treat the June 1 billing change as a good excuse to inspect the workflow before the invoice does it for you.

Start with visibility. Check which repositories use automatic reviews, which runners they use, and how frequently reviews run. Put a budget in place, even if it is generous. A budget is an alerting mechanism before it is a restriction.

Then sample the output.

Take a few weeks of review comments and classify them. Useful defect catch. Helpful suggestion. Style preference. Duplicate of an existing check. Wrong. Ignored.

You do not need a complicated dashboard on day one. A spreadsheet and an honest conversation will tell you more than a vanity metric.

Finally, decide where AI review belongs in the pipeline.

Maybe it runs automatically on critical services. Maybe authors request it before asking for human review. Maybe small dependency bumps skip it. Maybe security-sensitive changes get a more deliberate policy.

The correct answer will depend on the codebase.

That is the point.

the punchline

AI code review is becoming infrastructure.

It consumes model credits. It can consume runner minutes. It generates operational data. It needs defaults, budgets, and a reason to exist in each workflow.

That does not make it less useful.

It makes the engineering conversation more honest.

"Let the AI review everything" sounds like a productivity strategy until every pull request spends compute and every comment spends attention.

The teams that get value from AI review will not be the teams with the most automated comments.

They will be the teams that know which reviews are worth paying for.

references

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

some Kubernetes vulnerabilities do not have patches

Paulo Victor Leite Lima Gomes — Mon, 01 Jun 2026 00:01:38 +0000

There is a comforting rhythm to vulnerability management.

A scanner finds a CVE. Someone opens a ticket. You upgrade a package. The scanner goes green again.

It is not glamorous work, but at least the shape of the problem is familiar.

Today, some Kubernetes teams are going to get a reminder that security does not always work like that.

The Kubernetes Security Response Committee is correcting the records for three older CVEs on June 1, 2026. The records previously suggested that fixed versions existed. They do not. These are architectural risks that remain present across Kubernetes versions, and scanners may start reporting them in clusters where they were not reported before.

That sounds like a paperwork update.

It is also a useful test of whether your vulnerability program understands the difference between patching software and owning a system.

the scanner is not wrong

The three CVEs are not new:

CVE-2020-8561: the API server follows redirects when calling admission webhooks
CVE-2020-8562: a DNS time-of-check to time-of-use race can bypass API server proxy IP restrictions
CVE-2021-25740: write access to Endpoints and EndpointSlices can be used to forward traffic across namespace boundaries

The first two are low-to-medium severity. The third is low severity. None of this is a reason to declare an incident because a dashboard changed color overnight.

But none of it should be dismissed either.

The corrected records matter because vulnerability scanners depend on version ranges. If a CVE record says a fixed version exists, the scanner may assume a newer cluster is safe. Once the record says all versions are affected, the finding appears again.

Your cluster did not suddenly become less secure on June 1.

The data describing the risk became more honest.

That is good. Slightly annoying, but good.

some features are also attack surfaces

The interesting part is why these CVEs remain unfixed.

Take the admission webhook redirect issue. The API server uses ordinary HTTP client behavior when talking to admission webhooks. Following redirects is useful for legitimate integrations. It can also let someone who can configure a webhook redirect requests toward internal networks.

Or take the DNS proxy issue. The API server validates an IP after resolving a hostname, then resolves again when making the connection. An attacker who can manipulate the answers may exploit the gap. Pinning the first resolved IP sounds obvious until you remember split-horizon DNS and dynamic environments exist for real reasons.

The endpoint issue is even more familiar. Kubernetes allows endpoint objects to refer to manually specified IP addresses because networking tools and operators rely on that flexibility. The same flexibility can be abused to point traffic somewhere a namespace owner should not be able to reach.

These are not bugs in the usual sense.

They are examples of a platform being flexible enough to create dangerous combinations.

Removing the behavior would break valid workloads. Keeping the behavior means administrators need to constrain who can use it and how the control plane resolves or records it.

upgrade is not a universal security strategy

I have seen plenty of security programs organized around a simple metric: how quickly can we close scanner findings?

That metric is useful until it becomes the whole strategy.

When every finding is treated like a package upgrade, the workflow gets weird around architectural risks. Teams either keep searching for a version that does not exist, suppress the alert without understanding it, or leave a ticket open forever so the dashboard can remind everyone that nobody knows what to do.

None of those outcomes improve security.

The better question is:

What control owns this risk now that a patch does not?

For these Kubernetes CVEs, the upstream recommendations are concrete:

Keep API server verbosity below 10 and disable dynamic profiling with --profiling=false
Use a local caching resolver such as dnsmasq for the API server so DNS answers remain consistent between validation and connection
Restrict write access to Endpoints and EndpointSlices, especially on clusters upgraded from versions before Kubernetes 1.22

That last point is worth checking carefully. Newer clusters no longer grant those endpoint write permissions through the default aggregated edit and admin roles. Older clusters that were upgraded may still carry the broader permissions unless someone reconciled them.

This is the sort of small historical detail that quietly survives three platform migrations and then appears in a security review at the worst possible time.

configuration is part of the security boundary

There is a broader lesson here for platform teams.

We often talk about Kubernetes security as if it lives in release notes: stay supported, patch quickly, scan images, rotate credentials, repeat.

That work matters. But a Kubernetes cluster is not secure merely because it runs a recent version.

The API server flags matter.

The DNS path from the control plane matters.

The permissions inherited by roles created years ago matter.

The list of people and controllers allowed to write networking objects matters.

The dangerous part is that configuration risks rarely have the satisfying closure of an upgrade. You cannot point to a new version number and move on. You need an explicit control, a test for that control, and an owner who notices when the environment drifts.

This is less exciting than patching a zero-day.

It is also most of the job.

what i would do today

If these findings appear in your scanner, do not start with a blanket exception.

Start by separating the inventory from the mitigation:

Confirm which clusters are reporting the corrected CVEs.
Check API server verbosity and profiling configuration.
Review how control plane DNS resolution works, particularly in managed environments where you may need the provider's guidance.
Audit who can create admission webhook configurations.
Audit write access to Endpoints and EndpointSlices, including inherited and aggregated RBAC roles.
Record the mitigation as a control with an owner and a periodic check.

For managed Kubernetes, some controls may sit with the cloud provider. That is not a reason to ignore the finding. It is a reason to document the responsibility boundary clearly and verify what the provider actually guarantees.

Also, test changes in a non-production cluster. These risks remain unfixed precisely because the obvious fixes can break legitimate behavior. A security improvement that takes down internal networking is still an incident.

the punchline

The Kubernetes project is doing the right thing here.

Correcting old CVE records may create scanner noise, but inaccurate green dashboards are worse. Mature vulnerability data should tell you when a risk persists, even when the answer is not a neat upgrade command.

Some security findings are patch tickets.

Some are architecture decisions with mitigations.

The important thing is knowing which one you are looking at before you close the alert.

references

kubernetes is admitting that a pod is not always the unit of work

Paulo Victor Leite Lima Gomes — Sun, 31 May 2026 00:01:55 +0000

For a long time, the Kubernetes scheduler had a pleasantly simple job.

Look at a Pod. Look at the available nodes. Find somewhere the Pod can run.

That model is still useful. It is also starting to show its age.

Kubernetes v1.36 keeps pushing workload-aware scheduling forward with a revised Workload API, a new runtime PodGroup API, and an atomic PodGroup scheduling cycle. The short version is that Kubernetes is getting better at treating a group of related Pods as one scheduling decision.

This sounds like scheduler plumbing because it is scheduler plumbing.

But the reason it matters is much less abstract: sometimes running three quarters of a workload is not graceful degradation. It is just an expensive way to do nothing.

pods were a good unit of abstraction

The Pod has been one of Kubernetes' best ideas.

It gives us a small unit that can be scheduled, restarted, observed, scaled, and reasoned about. For web applications and a lot of background work, Pod-by-Pod scheduling is exactly right. If ten replicas are desired and only eight fit immediately, those eight can start serving traffic while the cluster figures out the rest.

Distributed training jobs, HPC workloads, and some batch systems are different.

Imagine a training job with 64 workers. Each worker needs an accelerator. The workers also need to communicate with each other. If Kubernetes schedules 47 of them and leaves the others pending, the running Pods are not necessarily useful. They may sit there holding expensive resources while the job waits.

The cluster looks busy.

The cloud bill looks busy.

The actual work does not.

That is the gap workload-aware scheduling is trying to close.

gang scheduling is a very honest name

The basic idea is gang scheduling: related Pods should be scheduled together.

Kubernetes v1.35 introduced the first tranche of workload-aware scheduling improvements, including the foundational Workload API and basic gang scheduling support. In v1.36, the architecture gets clearer.

The Workload API acts as the static template: what is this multi-Pod application supposed to look like?

The new PodGroup API represents runtime state: which Pods belong together for scheduling?

The scheduler then gets a PodGroup scheduling cycle that evaluates the group atomically. Either all Pods in the group can be bound together, or none of them are.

That last part is the important one.

Previously, it was easy to end up with fragmented scheduling: some workers running, others pending, and scarce hardware stranded in the middle. Atomic scheduling makes the scheduler acknowledge the real application contract.

The application does not need a Pod.

It needs the workload.

cloud abstractions keep meeting physics

I wrote earlier this week about Kubernetes Dynamic Resource Allocation and the way AI hardware is becoming an API contract. DRA makes specialized devices easier for the scheduler and platform to reason about.

Workload-aware scheduling is the next layer of the same problem.

A distributed job does not only need accelerators. It may need enough accelerators at the same time, in a useful topology, with networking that does not turn synchronization into a tax.

This is where clean cloud abstractions run into physical constraints.

You cannot autoscale your way out of a workload that needs 64 devices together when the cluster has 47 available. You cannot call partial scheduling a success if every allocated device is waiting for the missing workers. You cannot hide topology forever when communication costs dominate the job.

The scheduler needs to understand more of the intent.

That does not mean every user should become a scheduler expert. It means the platform needs a better place to express the dangerous constraints.

the job controller integration is the practical bit

The upstream architecture is interesting, but the Job controller integration is what makes this feel real.

With the WorkloadWithJob feature gate enabled, Kubernetes v1.36 can create and manage the Workload and PodGroup objects for qualifying Jobs. It sets the scheduling group on the Pods and lets the scheduler treat them as a single gang.

There are deliberately narrow conditions for this first iteration:

parallelism must be greater than one
the completion mode must be Indexed
completions must equal parallelism
the Pod template must not already set a scheduling group

That is a reasonable starting point. Static, fully parallel Jobs are the easiest workload shape to reason about. The scheduler knows how many Pods need to arrive together, and each Pod has a stable identity.

Elastic jobs and more complex controller shapes can come later.

This is also all alpha in v1.36. The relevant feature gates are not something to casually flip on in production because a blog post made them sound neat. But alpha features are useful signals. They show which problems are important enough that Kubernetes is making room for them in the control plane.

partial capacity is not always better than zero

Most platform instincts are built around graceful degradation.

If you cannot have ten replicas, run eight. If the preferred zone is full, schedule elsewhere. If the ideal node type is unavailable, use a slightly more expensive one. Keep moving.

Those instincts are good for services. They can be wrong for coordinated workloads.

For a tightly coupled job, partial capacity can be worse than zero:

it consumes expensive devices without producing useful progress
it blocks other jobs that could use those devices immediately
it makes utilization dashboards look healthier than the business outcome
it creates operational confusion because Pods are technically running

This is the kind of infrastructure failure that hides inside a green dashboard.

The platform reports allocation.

The user experiences waiting.

The finance team experiences a bill.

Gang scheduling makes that mismatch harder to ignore.

this changes capacity planning too

Once the scheduler can reason about whole workloads, capacity planning becomes more honest.

It is not enough to say that the cluster has 300 accelerators free. The useful questions become:

Can it place the next 64-worker training job?
Which workloads are blocked by fragmented capacity?
How much hardware is allocated to incomplete groups?
Should a smaller job run first while the large job waits?
When is preemption worth the disruption?
Which topology constraints are driving pending time?

Those questions are harder than counting free devices.

They are also the questions platform teams actually need answered when expensive compute is involved.

This is why I think scheduling work deserves more attention than it usually gets. The scheduler is not merely packing containers onto machines. It is deciding whether scarce capacity turns into useful work or expensive waiting.

what i would do now

If you run batch, AI, or HPC workloads on Kubernetes, I would not start by enabling every alpha feature.

I would start by measuring how often partial scheduling hurts today.

Look for jobs with some Pods running and others pending. Measure how long expensive devices sit allocated before the full job starts making progress. Check whether fragmentation is preventing useful work even when aggregate free capacity looks reasonable. Ask whether your existing batch system or custom scheduler is carrying logic the native platform may eventually absorb.

Then experiment in a test cluster.

The useful question is not "can we adopt the new API immediately?"

It is "which hidden scheduling assumptions are already costing us money?"

That answer will tell you whether workload-aware scheduling is a future curiosity or a roadmap item.

the punchline

Kubernetes spent years teaching us to think in Pods.

That was a good abstraction. It still is.

But abstractions have boundaries, and distributed workloads are making this one visible. A Pod can be schedulable while the application is not. A cluster can look utilized while useful work is stalled. A partial allocation can be more expensive than waiting.

The scheduler is learning to represent that reality.

First it learned to place Pods.

Now it is learning that sometimes the Pod was never the real unit of work.