Clark - An AI coworker with its own cloud computer
by•
Clark is an AI coworker with its own cloud computer - browser, terminal, files, and code. Hand it a real task, close the tab, and come back to finished work: wide, sourced research; websites; spreadsheets; decks; audits; or tested code. It can fan work out to parallel specialists, run on a schedule, and return artifacts with the evidence behind them. Use Clark on web or mobile, work in real repositories with Clark Code, or embed the agent through an OpenAI-compatible API.
Replies
How does the fan out to parallel specialists actually work, does Clark decide on its own how to split a task or do you have to define the sub agents ahead of time?
@talhakhalidmtk it decides on its own
@stanislav_kirdey great
the scheduled monitoring use case is the interesting one - when a monitor job runs repeatedly, does it diff against the last run so you only get pinged on what changed, or does it hand back the full state fresh each time and you compare yourself?
@sabber_ahamed it diffs against last run so it is continous information, not same thing every day
A cost and token usage breakdown for every completed task would be really helpful, especially for teams running large research or coding workflow.
@ill_robyn will add! 💜
@umar_saleem clark code
www.clarkchat.com/clark-code should be able to navigate them with ease!
"Its own cloud computer" is a meaningfully different architecture than most AI-coworker tools that just call APIs — giving it a persistent environment changes what it can actually do end-to-end. Curious how you're handling security/sandboxing for that computer, especially once it's doing real multi-step tasks unsupervised. That's usually the part that keeps teams from trusting autonomous agents with anything consequential.
an AI coworker with its own cloud computer is a wild framing. curious how you handle the case where it needs to install something or hit a paywall/captcha mid-task - does it just stall out and ping you, or does it have some way to work around that on its own?
@omri_ben_shoham1 it will try to solve it, and if it needs to login somewhere it willl ask you to take over browser and provide credentials
the sandboxing/state questions above cover the trust side well. curious about the fan-out mechanic specifically - when Clark splits a task across parallel specialists, do they each get an isolated environment that gets merged into the final artifact, or do they share the same cloud computer/workspace while running concurrently? asking because shared-state parallelism is where I'd expect the weird bugs to show up first
@galdayan full isolated clarks with full browser and filesystem work in parallel and merge into final artifact
@stanislav_kirdey Full isolation makes sense - avoids exactly the shared-state race conditions I was worried about, at the cost of a merge step at the end. Is that merge automatic (Clark reconciling the artifacts itself) or does it flag conflicts for the user to resolve manually?
the scheduled monitoring runs are the part I'd worry about most - if a recurring job silently starts failing (site changed, credentials expired) does it flag that as a failure or just quietly hand back a stale/empty artifact next run?
@sabber_ahamed there is a flag it will stop wasting tokens if it fails
the scheduled monitor use case is the one I'd want most out of this. when it re-runs on a timer, does it diff against the last artifact and surface only what changed, or hand back a fresh full artifact every time and leave the comparison to you?
Love that Clark can fan work out to parallel specialists and hand back artifacts with sources. One thing I'd love is a simple "trust but verify" mode where I can quickly diff what Clark did against my own expectations before it writes to a repo or ships a spreadsheet, so I can catch small errors without babysitting the run.
@ebru1lid great feature request!