solid pick-your-harness infra. I like that it's not locked to one agent runtime, you can point it at whichever coding agent you already use and just pay for the time it's actually running instead of a flat seat fee. setup was quick and it plays nicely with existing workflows over chat, which is the part that usually breaks with these managed-agent products.
What needs improvement
more visibility into what's actually running and for how long would help - right now it's a bit of a black box until the bill shows up, some kind of live status or running-cost indicator per agent would go a long way.
vs Alternatives
looked at a couple of the self-hosted always-on agent setups first, but didn't want to manage the sandboxing and uptime myself for something I run occasionally.
Hey Product Hunt community — Thanks for the overwhelming interest and questions! We're doing a live workalong session on Wednesday night PST where you can bring your bot, ship it to the cloud in minutes, and get more questions answered live. Join here:lu.ma/e94dqa2m
---
Hey Product Hunt! 👋
I built AgentSky because production-ready AI agents require far more infrastructure than most people expect. The idea came from building tycoon.us, where we ran into the same challenges: testing multiple harness/LLM combinations (let alone harness version updates 😱), fast & secure sandboxes, surviving restarts, and connecting them to every channel users expect.
AgentSky does that plumbing for you. Pick a harness — Claude Code, Codex, Hermes, or OpenClaw — pick a model, and launch in one click, or a CLI command. Your agent runs always-on in its own cloud sandbox with full history, artifacts persistence, state snapshots, backup and restore.
It's reachable wherever your users already are — WhatsApp, iMessage, Telegram, Slack, web, CLI, or our developer API's. Same protocol, same memory, every harness, every channel.
Already battle-tested in production, AgentSky powers tycoon.us, where it has handled over 10K+ agent sessions.
Parking an agent is free — you only pay when it's actively working.
Would love your feedback, especially on which runtimes and channels you'd want next!
Report
Suspend and resume is the interesting part, and I think it has a blind spot worth designing for now rather than later.
If parking is free and I only pay while the agent is working, then an agent that has quietly stopped working costs me nothing. Which is lovely, right up until a dead agent and a cheap month look identical on the invoice. For long horizon work the bill has historically been the thing that told people something had gone wrong, and this pricing removes that signal on purpose.
From outside, a suspended agent, a finished agent, and one that crashed and never resumed all present the same way. No activity, no cost, nothing in the channel. So what tells the operator which of the three they have? What I would want is for a long horizon agent to declare an expected cadence when it launches, so the platform can say this one should have woken by now and has not, instead of leaving silence to mean whatever the reader assumes it means.
Second one, and it falls out of snapshots combined with messaging channels. If you snapshot state and restore it, what happens when the snapshot was taken partway through an external side effect? An agent restored to a point just before it sent a WhatsApp message cannot tell whether that message went. Redoing it and skipping it are both wrong, and only one of those is visible to the person on the other end, who receives it twice.
Do side effects get recorded outside the snapshot, so a resumed agent knows what already left the building?
1. Dead vs idle. Crashed agents fail health check, while idle agents mean that it is healthy but no request incoming to handle. Btw, we have built-in health check for agents. 2. Our state restoring is best effort based, it cannot prevent race condition, but it would at least make the agent remember partially (usually the latest conversation).
What you brought up is very meaningful and sophisticated. I also believe that each product may have different opinions on these behaviors.
Report
@darren_y_lu Thanks, both useful. Pushing on the first one, because I think the health check answers a different question from the one that bites.
A health check tells you the process is alive. It does not tell you the work moved. Those two come apart exactly in long horizon agents, which is the case you are built for. An agent stuck on the same step for six hours is healthy. An agent waiting on a webhook that will never fire is healthy. An agent that finished twenty minutes ago is healthy. All three pass the check, and all three are indistinguishable from idle.
I have had precisely this. Scheduled work stopped and every check kept answering correctly, because the machine was up, the job was scheduled, and nothing was in an error state, because nothing had errored. What had actually stopped was not a unit anything was watching.
So the signal I would put next to the health check is last progress rather than last heartbeat. Something the agent advances only when it completes a unit of work, plus a declared expectation of how often that should happen. That is what stops healthy and stuck being the same state.
On the second, agreed it cannot be solved in general, but I would cut it differently than by product. It is not really a matter of opinion, it is reads versus side effects. Best effort on a read is fine, you fetch again and nobody notices. Best effort on a send means a customer gets the same WhatsApp message twice, and no amount of application level opinion prevents that.
The reason I would put it on your side rather than the app's is that you own the channel adapters. If an outbound side effect carries a stable idempotency key generated before the attempt, the adapter can drop the duplicate on resume without the agent ever needing to know it was restored. Stripe solved the same problem the same way. An app developer cannot, because they are not sitting at the point where the message actually leaves.
@dalemooney Correct. Health check is just a line of defense, it is not ground truth. We want to keep the system simple, stupid, as infra layer. I agree that product would have to multiple checks to find out if an agent is really healthy.
Idempotency for agent reply is good idea, we will figure out how to do it in our layer. Thanks for the detailed discussion, you definitely had put a lot thoughts into those real world problems!
Report
congratulations!can agents communicate with users across multiple channels simultaneously? for example, could an agent start on Slack and continue the same conversation on WhatsApp?
@daniel_harris11 > could an agent start on Slack and continue the same conversation on WhatsApp?
Yes, that is what we do. Internally AgentSky agent handle all channels uniformly. This is the magic that it can maintain continuous context among channels. This is a feature we needed at our own agent product before, so that we built it.
The multi-channel consistency is the part I want to understand better. If a user starts a thread on Telegram and then messages from Slack the next day, does the agent see a single unified conversation or two separate sessions? For developer communities I manage, people switch channels constantly and that is usually where context breaks happen.
@hazy0 Great question. In AgentSky, a single agent session can be shared on multiple channels, but it will only reply to the channel where request was sent. And the session context are all shared for same agent session. We designed specifically for cross-channel smooth experience. Do you think this behavior is the common denominator for most products?
Report
The biggest challenge I see with multi-channel agents is maintaining context. If someone asks a technical question in a community forum today and follows up with the same issue in a private chat tomorrow, how does the agent know it’s the same user and the same problem?
Is the conversation history unified at the agent level, or does each platform maintain its own separate memory?
@new_user___140202597473f65134ed0cb Great question. In AgentSky, conversation history is unified at agent instance level, so yeah it is agent level, not per channel. We designed the system so that a single agent can talk to multiple channels at the same time.
Report
congrats!can one agent use different models depending on the task it is performing? for example could it use a cheaper model for simple tasks and a stronger one for complex reasoning?
@olivia_bennett7 Thanks! AgentSky does not support harness/model routing, but it is indeed on our roadmap. Do you have any suggestions on what routing framework we should look into?
Report
how does AgentSky handle failed or partially completed tasks? can an agent resume from its previous state instead of starting over?
Hey Product Hunt community — Thanks for the overwhelming interest and questions! We're doing a live workalong session on Wednesday night PST where you can bring your bot, ship it to the cloud in minutes, and get more questions answered live. Join here:lu.ma/e94dqa2m
---
Hey Product Hunt! 👋
I built AgentSky because production-ready AI agents require far more infrastructure than most people expect. The idea came from building tycoon.us, where we ran into the same challenges: testing multiple harness/LLM combinations (let alone harness version updates 😱), fast & secure sandboxes, surviving restarts, and connecting them to every channel users expect.
AgentSky does that plumbing for you. Pick a harness — Claude Code, Codex, Hermes, or OpenClaw — pick a model, and launch in one click, or a CLI command. Your agent runs always-on in its own cloud sandbox with full history, artifacts persistence, state snapshots, backup and restore.
It's reachable wherever your users already are — WhatsApp, iMessage, Telegram, Slack, web, CLI, or our developer API's. Same protocol, same memory, every harness, every channel.
Already battle-tested in production, AgentSky powers tycoon.us, where it has handled over 10K+ agent sessions.
Parking an agent is free — you only pay when it's actively working.
Would love your feedback, especially on which runtimes and channels you'd want next!
Suspend and resume is the interesting part, and I think it has a blind spot worth designing for now rather than later.
If parking is free and I only pay while the agent is working, then an agent that has quietly stopped working costs me nothing. Which is lovely, right up until a dead agent and a cheap month look identical on the invoice. For long horizon work the bill has historically been the thing that told people something had gone wrong, and this pricing removes that signal on purpose.
From outside, a suspended agent, a finished agent, and one that crashed and never resumed all present the same way. No activity, no cost, nothing in the channel. So what tells the operator which of the three they have? What I would want is for a long horizon agent to declare an expected cadence when it launches, so the platform can say this one should have woken by now and has not, instead of leaving silence to mean whatever the reader assumes it means.
Second one, and it falls out of snapshots combined with messaging channels. If you snapshot state and restore it, what happens when the snapshot was taken partway through an external side effect? An agent restored to a point just before it sent a WhatsApp message cannot tell whether that message went. Redoing it and skipping it are both wrong, and only one of those is visible to the person on the other end, who receives it twice.
Do side effects get recorded outside the snapshot, so a resumed agent knows what already left the building?
@dalemooney Great questions!
1. Dead vs idle. Crashed agents fail health check, while idle agents mean that it is healthy but no request incoming to handle. Btw, we have built-in health check for agents.
2. Our state restoring is best effort based, it cannot prevent race condition, but it would at least make the agent remember partially (usually the latest conversation).
What you brought up is very meaningful and sophisticated. I also believe that each product may have different opinions on these behaviors.
@darren_y_lu Thanks, both useful. Pushing on the first one, because I think the health check answers a different question from the one that bites.
A health check tells you the process is alive. It does not tell you the work moved. Those two come apart exactly in long horizon agents, which is the case you are built for. An agent stuck on the same step for six hours is healthy. An agent waiting on a webhook that will never fire is healthy. An agent that finished twenty minutes ago is healthy. All three pass the check, and all three are indistinguishable from idle.
I have had precisely this. Scheduled work stopped and every check kept answering correctly, because the machine was up, the job was scheduled, and nothing was in an error state, because nothing had errored. What had actually stopped was not a unit anything was watching.
So the signal I would put next to the health check is last progress rather than last heartbeat. Something the agent advances only when it completes a unit of work, plus a declared expectation of how often that should happen. That is what stops healthy and stuck being the same state.
On the second, agreed it cannot be solved in general, but I would cut it differently than by product. It is not really a matter of opinion, it is reads versus side effects. Best effort on a read is fine, you fetch again and nobody notices. Best effort on a send means a customer gets the same WhatsApp message twice, and no amount of application level opinion prevents that.
The reason I would put it on your side rather than the app's is that you own the channel adapters. If an outbound side effect carries a stable idempotency key generated before the attempt, the adapter can drop the duplicate on resume without the agent ever needing to know it was restored. Stripe solved the same problem the same way. An app developer cannot, because they are not sitting at the point where the message actually leaves.
@dalemooney Correct. Health check is just a line of defense, it is not ground truth. We want to keep the system simple, stupid, as infra layer. I agree that product would have to multiple checks to find out if an agent is really healthy.
Idempotency for agent reply is good idea, we will figure out how to do it in our layer. Thanks for the detailed discussion, you definitely had put a lot thoughts into those real world problems!
congratulations! can agents communicate with users across multiple channels simultaneously? for example, could an agent start on Slack and continue the same conversation on WhatsApp?
@daniel_harris11
> could an agent start on Slack and continue the same conversation on WhatsApp?
Yes, that is what we do. Internally AgentSky agent handle all channels uniformly. This is the magic that it can maintain continuous context among channels. This is a feature we needed at our own agent product before, so that we built it.
The multi-channel consistency is the part I want to understand better. If a user starts a thread on Telegram and then messages from Slack the next day, does the agent see a single unified conversation or two separate sessions? For developer communities I manage, people switch channels constantly and that is usually where context breaks happen.
@hazy0 Great question. In AgentSky, a single agent session can be shared on multiple channels, but it will only reply to the channel where request was sent. And the session context are all shared for same agent session. We designed specifically for cross-channel smooth experience. Do you think this behavior is the common denominator for most products?
The biggest challenge I see with multi-channel agents is maintaining context. If someone asks a technical question in a community forum today and follows up with the same issue in a private chat tomorrow, how does the agent know it’s the same user and the same problem?
Is the conversation history unified at the agent level, or does each platform maintain its own separate memory?
@new_user___140202597473f65134ed0cb Great question. In AgentSky, conversation history is unified at agent instance level, so yeah it is agent level, not per channel. We designed the system so that a single agent can talk to multiple channels at the same time.
congrats! can one agent use different models depending on the task it is performing? for example could it use a cheaper model for simple tasks and a stronger one for complex reasoning?
@olivia_bennett7 Thanks! AgentSky does not support harness/model routing, but it is indeed on our roadmap. Do you have any suggestions on what routing framework we should look into?
how does AgentSky handle failed or partially completed tasks? can an agent resume from its previous state instead of starting over?
@luz_bidelspach AgentSky does recover into latest state from crash. We do not "starting over" any tasks when agent recovers from context backup.