Decawork is how IT teams take employee-built AI agents live and control every one of them from one place. An employee builds an agent on Claude Code, Codex, or any vibecoding tool; we take it in, put it on company accounts, and run it as a company asset. From there, IT team manages the agent like an employee: access, oversight, retirement.
AI coding tools made it easy for anyone to build an internal agent. The hard part starts when a teammate wants to use it. Now the agent needs company credentials, access to real systems, an owner, approvals, logs, maintenance, and a way for IT to stop it.
Decawork handles that handoff. Your team still owns the job. Bring us the repo from Claude Code, Codex, Cursor, or whatever your team used. Decawork operates the agent with a company identity. IT decides what it can access, reviews sensitive actions, sees what it did, and can pause or retire it from one place.
We think internal AI is unlocked by IT, not by one more agent builder. IT should not have to choose between blocking every experiment and rebuilding each one by hand.
We've spent years on both sides of this handoff. I built AI systems at NVIDIA that shipped to OpenAI and Meta, then enterprise agents for Microsoft and Hitachi. Aman (my co-founder) built Barclays' AI compliance platform, led a consumer AI product to 100K+ monthly users, and founded a fintech serving 52K families.
We'd love feedback from people building internal agents, especially the IT and security teams asked to let them touch company systems. What was the first thing that broke when your agent moved beyond its original builder?
@shubhampalriwala Yes, that’s a core use case. Decawork connects internal agents to company tools through an IT-controlled gateway, with scoped access for each agent.
@anthony_adams_ Exactly. Retiring an agent should revoke its access and credentials cleanly, without leaving shadow infrastructure behind.
Report
I’d be interested in seeing audit logs for agent activity, especially for teams handling customer or financial data.
Report
Super interesting! Philosophically in alignment with you about having an AI stack that isn't locked into one provider.
One question, since often security is part technical and part behavioral: what steps of behavioral change do employees need to take for this to work?
Report
This is a real problem I’ve been seeing with startups - someone on the team builds agents that run on personal keys, with no audit trail and everything is all over the place with no central identity or control.
Report
Access control is probably going one of the biggest challenges of the agent era. Having everything managed from one place a lot of sense.
@victor_coleman That’s the hard part. Identity alone isn’t enough. IT needs to know which agent has access to what, who approved it, and be able to change or revoke that access centrally.
Decawork
Hey Product Hunt, I'm Sarthak - co-founder of Decawork (YC S26).
AI coding tools made it easy for anyone to build an internal agent. The hard part starts when a teammate wants to use it. Now the agent needs company credentials, access to real systems, an owner, approvals, logs, maintenance, and a way for IT to stop it.
Decawork handles that handoff. Your team still owns the job. Bring us the repo from Claude Code, Codex, Cursor, or whatever your team used. Decawork operates the agent with a company identity. IT decides what it can access, reviews sensitive actions, sees what it did, and can pause or retire it from one place.
We think internal AI is unlocked by IT, not by one more agent builder. IT should not have to choose between blocking every experiment and rebuilding each one by hand.
We've spent years on both sides of this handoff. I built AI systems at NVIDIA that shipped to OpenAI and Meta, then enterprise agents for Microsoft and Hitachi. Aman (my co-founder) built Barclays' AI compliance platform, led a consumer AI product to 100K+ monthly users, and founded a fintech serving 52K families.
We'd love feedback from people building internal agents, especially the IT and security teams asked to let them touch company systems. What was the first thing that broke when your agent moved beyond its original builder?
Find a time at decawork.ai or reach out at sarthak@decawork.ai.
A friend of mine ran into an issue at his company where they couldn't connect tools to their internal agents, do y'all take care of those as well?
Decawork
@shubhampalriwala Yes, that’s a core use case. Decawork connects internal agents to company tools through an IT-controlled gateway, with scoped access for each agent.
Serand
I like the employee-style lifecycle for agents. Having a clear way to retire old agents could prevent a lot of security headaches.
Decawork
@anthony_adams_ Exactly. Retiring an agent should revoke its access and credentials cleanly, without leaving shadow infrastructure behind.
I’d be interested in seeing audit logs for agent activity, especially for teams handling customer or financial data.
Super interesting! Philosophically in alignment with you about having an AI stack that isn't locked into one provider.
One question, since often security is part technical and part behavioral: what steps of behavioral change do employees need to take for this to work?
This is a real problem I’ve been seeing with startups - someone on the team builds agents that run on personal keys, with no audit trail and everything is all over the place with no central identity or control.
Access control is probably going one of the biggest challenges of the agent era. Having everything managed from one place a lot of sense.
Decawork
@victor_coleman That’s the hard part. Identity alone isn’t enough. IT needs to know which agent has access to what, who approved it, and be able to change or revoke that access centrally.