Most AI tools stop at the chat box. AGNT Hub gives you a private AI workspace running inside an isolated cloud container. Add custom skills, connect tools like Notion via MCP, and build workflows once. Let your agents run in the background without touching Docker, AWS, or config files.
We built AGNT Hub because most AI products still live inside a chat window.
That’s fine for quick answers. It breaks when you want AI connected to the work you actually use every day.
The moment you try to make that setup private and server-based, it usually turns into infrastructure work.
Docker. AWS. API keys. Config files. Local scripts that stop the moment your laptop closes.
AGNT Hub makes that setup usable for non-technical operators.
You sign up, get a private AI workspace running on a dedicated server, connect your tools through MCP, add skills from the marketplace or bring your own, and let agents run from the server instead of your machine.
If your last AI setup died the moment your laptop closed – this one won't.
Report
I think this is a great solution because it takes effort to set up your dev environment and the focus on non technical users is great as well because this is a category that is exploring these tools more and more and does require better setup to explore different tools. How do you handle the case if an agent is running a background workflow and then hits an error? Is this surfaced to the end user via some sort of notification system or is it moreso this is just the container and up to the user to handle this?
@lavaman131 At the moment, it’s largely up to the user to decide how to handle errors within their workflows. However, we’re actively working on a notification system that will surface such events automatically.
Our goal is to support multiple notification channels (in-app alerts, email, webhooks, etc.), so whenever an agent encounters an error while running a background workflow, users can be notified immediately and take action. Until then, error handling and recovery logic can be implemented through custom skills and workflow design.
I think an isolated cloud container for agents is a nice way to make this feel safer. Can you control outbound access, like restricting which domains or APIs the agent can call?
@thamibenjelloun We don’t have a dedicated page for these settings. However, you can create a custom skill and assign it to your agent, which will give you this level of control.
Report
Nice launch. The dedicated server angle makes sense, especially for agents that should keep running after the laptop closes.
The two questions already here, error handling and outbound controls, feel like the real production boundary. Once an agent can run background workflows with MCP tools, do you see policy as something each custom skill owns, or as a central layer that says: this agent can read these tools, propose these writes, auto-run these low-risk actions, and require approval for the risky ones?
That feels like the difference between a useful hosted agent and a tiny autonomous intern with root access.
Report
The marketplace plus bring your own skills combo is smart. Do new users tend to activate faster grabbing a ready skill from the marketplace, or building their own first? Wondering which path gets them to "this actually works" quicker.
Great launch Anton! Always-on AI agents without server management is the dream for indie builders — the infra overhead of keeping agents alive 24/7 is a real pain point. What's the cold-start behavior like when an agent hasn't been triggered in a while?
Report
Always-on agents without server setup is a genuinely useful angle.
One question: at what point could a non-technical operator run a workspace here — without you or the original team involved?
AGNT.Hub
I think this is a great solution because it takes effort to set up your dev environment and the focus on non technical users is great as well because this is a category that is exploring these tools more and more and does require better setup to explore different tools. How do you handle the case if an agent is running a background workflow and then hits an error? Is this surfaced to the end user via some sort of notification system or is it moreso this is just the container and up to the user to handle this?
AGNT.Hub
@lavaman131 At the moment, it’s largely up to the user to decide how to handle errors within their workflows. However, we’re actively working on a notification system that will surface such events automatically.
Our goal is to support multiple notification channels (in-app alerts, email, webhooks, etc.), so whenever an agent encounters an error while running a background workflow, users can be notified immediately and take action. Until then, error handling and recovery logic can be implemented through custom skills and workflow design.
Mailwarm
I think an isolated cloud container for agents is a nice way to make this feel safer. Can you control outbound access, like restricting which domains or APIs the agent can call?
AGNT.Hub
@thamibenjelloun We don’t have a dedicated page for these settings. However, you can create a custom skill and assign it to your agent, which will give you this level of control.
Nice launch. The dedicated server angle makes sense, especially for agents that should keep running after the laptop closes.
The two questions already here, error handling and outbound controls, feel like the real production boundary. Once an agent can run background workflows with MCP tools, do you see policy as something each custom skill owns, or as a central layer that says: this agent can read these tools, propose these writes, auto-run these low-risk actions, and require approval for the risky ones?
That feels like the difference between a useful hosted agent and a tiny autonomous intern with root access.
The marketplace plus bring your own skills combo is smart. Do new users tend to activate faster grabbing a ready skill from the marketplace, or building their own first? Wondering which path gets them to "this actually works" quicker.
Loomal
Great launch Anton! Always-on AI agents without server management is the dream for indie builders — the infra overhead of keeping agents alive 24/7 is a real pain point. What's the cold-start behavior like when an agent hasn't been triggered in a while?
Always-on agents without server setup is a genuinely useful angle.
One question: at what point could a non-technical operator run a workspace here — without you or the original team involved?