Decawork

The most interesting thing about Decawork is what it does not do. It does not build agents. It does not claim to make your Claude Code or Codex setup smarter, faster, or more autonomous. Instead, Decawork sits on top of the agent your team already built and turns it into something IT can actually approve, monitor, and retire — like any other piece of company infrastructure.

That distinction matters because the hardest part of the internal AI wave was never the model. It was the governance. Developers can spin up an agent in an afternoon; IT has no standard way to say yes. Decawork's pitch is that it supplies the missing layer: an agent control plane for IT teams.

The agent your team already built is an IT problem now

Every company with a Claude Code or Codex user eventually hits the same wall. The agent works. It saves time. It writes decent code, drafts emails, or automates a vendor onboarding process. Then someone asks the obvious question: what happens when it touches a production database? Or a customer record? Or an internal API that should have been decommissioned last year?

That is the moment the agent stops being a developer toy and becomes an IT risk. Decawork's homepage makes the transition explicit: "Build in Claude Code, Codex, or anywhere else. Decawork deploys, governs, and maintains each agent with IT approval before launch." The emphasis is on the last clause — before launch. The product is not about enabling more agents; it is about making the ones that exist safe enough to run.

Public materials suggest the company is early — the site lists Y Combinator backing (S26) and a SOC 2 report, but pricing, docs, and a blog are all 404s. The product is being sold through live walkthroughs and founder emails, which fits a pre-general-availability tool for a very specific pain.

Deploy: the go-live checklist nobody had

The deploy section of Decawork's site shows a mock go-live checklist for an agent named agt_9d20b7. It is a small detail, but it reveals the core idea: an agent is treated like a new employee or a new server, not a script. The checklist includes identity creation, access scoping to two systems, monitoring on every run, a spending cap of $120 per month, and an IT sign-off that is pending.

That last item is the key. Most agent frameworks let a developer set up credentials and run. Decawork inserts an approval gate between the developer's intent and the agent's access. IT sees what the agent will be able to touch, how much it might cost, and what monitoring is in place — and then decides whether to approve go-live.

The spending cap is a particularly concrete detail. It suggests Decawork is designed for agents that make paid API calls or use external tools, not just internal code generation. A $120 monthly cap is a guardrail that most internal tools never had, because most internal tools never had a per-agent identity that could be billed separately.

Govern: scoped credentials and the approval that actually matters

Decawork's govern section shows a vendor onboarding agent passing through a gateway. The visual labels are telling: "No raw credentials," "Scoped," "Held for approval," "Attributed." Four words that summarize what IT has been asking for since the first agent appeared on a laptop.

Instead of giving an agent a shared service account or a developer's personal token, Decawork issues scoped credentials per agent. The agent can call the two systems IT approved, and nothing else. Sensitive actions wait for human approval; everything else is logged and attributed to the specific agent identity.

This is a meaningful departure from the way most teams run agents today. A developer might use their own API key, which means every agent action is attributed to a person, not a workload. That makes auditing a nightmare. Decawork's model separates the human from the agent: the developer builds, the agent runs under its own identity, and IT can see exactly which agent did what.

The approval flow is also notable because it is not just a one-time gate. The site says "sensitive actions wait for approval," which implies a runtime policy engine. An agent might be allowed to read a database but not write to it; to send an email but not to a distribution list. That level of granularity is rare in the early agent tooling space.

Maintain: what happens when the credential expires at 9:02 a.m.

Decawork's maintain section shows a real-world failure: an invoice reminder agent that runs every 30 minutes has paused because a credential expired. The status reads "17 / 18 succeeded," and IT is notified via Slack in the #it-alerts channel.

This is the part of agent operations that most tooling ignores. Agents are not set-and-forget; they depend on credentials, integrations, and external APIs that rot over time. A credential expires, an integration changes its API, or a vendor deprecates a field — and the agent silently fails. Decawork's answer is to watch every run, alert IT when something breaks, and give the team a clear path to restore, pause, or retire the agent.

The Slack notification is a small but important design choice. IT teams already live in Slack; they do not want to open another dashboard to learn that an agent is down. By pushing alerts into the existing channel, Decawork makes itself a background operator rather than another tool to check.

The maintain loop also closes the lifecycle. An agent can be paused, restarted with a new credential, or retired entirely. That is the difference between a script and a service. Decawork is trying to make agents as manageable as any other piece of infrastructure — with the same expectations for uptime, security, and accountability.

Why the control plane, not the agent, is the category

The agent market is crowded with builders — companies making agents that code, write, research, or automate. Decawork is not competing with them. It is competing with the chaos that those agents create inside a company. The control plane is the layer that makes agents safe to deploy at scale, and it is a category that is only starting to emerge.

Decawork's positioning as "the agent control plane for IT teams" is deliberately modest. It does not promise to make agents smarter. It promises to make them governable. That is the more valuable promise for any company with more than a handful of agents running against real systems.

The name itself — Decawork — suggests a platform that handles ten (deca) kinds of work, or perhaps a decathlon of agent operations. It is not a clever pun, but it does signal a broad operational scope. The domain decawork.ai is clean and category-appropriate, and the Y Combinator backing adds credibility.

What is missing from the public materials is any sense of pricing, onboarding time, or how the product handles agents built outside Claude Code and Codex. The site mentions "any stack," but the examples are all from the two most popular coding agents. That is a reasonable starting point, but the real test will be whether Decawork can govern agents built on custom frameworks or emerging tools.

For now, Decawork is making a focused bet: the agent is not the product; the control plane is. If IT teams are the bottleneck to agent adoption, then a tool that gives them visibility, approval, and recovery is not a nice-to-have — it is the thing that lets the company say yes.