Docker Agent could be beneficial for research studies. For example, while writing a ML paper about agents I need to rerun experiments so that:
- others can repeat my results
- validate that variability from LLMs is not causing overconfidence in the results
But currently uv is good enough to create isolated, repeatable environments. And it isn't limited to Linux like standard Docker. So when I want to test small samples on my local PC's GPU (Windows or mac) before running on beefier hardware, I can do that easily.
Go doesn't have a good mod/plugin story for harness devs to provide to their users
I say this as a gopher who also has a custom harness written in Go, it's a real challenge compared to the TS setups, but TS plugins are also a security concern
they hope they can annoy and email every person in the org asking for money , same way as they did it with docker.
looks like a weird abstractions. why do i need this if i have modal.com, e2b, cloudflare that use original docker + some toolings around + way to run + isolations on network level.
It frustrates me that there's a prisoners dilemma in communicating this to other humans. If I flag it and write it out (as you've done) I've let the author know that they're losing trust and let others know that they should be more skeptical. I've also created the perfect eval data pair for the ai labs. It's deeply frustrating.
There was a brief point in time at the beginning of the internet where if you saw an image online you could be kind of confident that it hadn't been manipulated significantly... But somewhere around the mid to late 2000s it became prudent to just assume any image you've seen online got at least a blemish filter pass through something like Photoshop.
Same thing now with written text. Sometimes you'll be a little bit more or less sure than an llm produced the output but never able to say 100% confidently.
You don't really have to use the docker agent sub-command. docker-agent is a standalone binary. When it was created, though, 1.5 year ago, the idea was that it would be the docker compose for agents (original name was cagent, compose for agents).
But it evolved differently and although it runs very well in docker containers and docker sandboxes, it also runs very well anywhere else.
It was created to be the docker compose for agents. 2 years ago, people, including ourselves, started to mix agentic loops and non agentic components in docker compose files. We created docker agent to make this more powerful.
At the end, the link with docker compose is just the yaml form. Which by the way can be replaced with hcl files or Go code.
Docker Agent predates Docker sandboxes. It was created almost two years ago when not everybody had a AI harness. Nowadays, it does run very well in Docker Sandboxes but it runs also very well anywhere you like.
Nowadays there are only two justifiable public languages you should be using for anything
a) C++
b) Rust
Rust itself is dubious due to abysmal compile times and the fact that the only guarantees it gives you are of security (aka a skill issue). Modern LLMs write C++ that is as safe if not safer than Rust. Any other language choice is objectively wrong.
* For those inquisitive enough the keyword "public" is doing all the heavy lifting here. Pretty much everyone should be developing and using an in-house DSL at this point.
https://docker.github.io/docker-agent/configuration/sandbox/
If, like me, you couldn't find any security-related info on the linked page.
i remember going through the entire docs of docker sandbox and there was not one mention of attack vectors. did they fix that?
Docker Agent could be beneficial for research studies. For example, while writing a ML paper about agents I need to rerun experiments so that: - others can repeat my results - validate that variability from LLMs is not causing overconfidence in the results
But currently uv is good enough to create isolated, repeatable environments. And it isn't limited to Linux like standard Docker. So when I want to test small samples on my local PC's GPU (Windows or mac) before running on beefier hardware, I can do that easily.
While I love new open source dev (especially in Go!), agent harnesses are turning into JS frameworks from yesteryear.
All the cool kids have one!
Coupled with VSCode forks to manage them
Go doesn't have a good mod/plugin story for harness devs to provide to their users
I say this as a gopher who also has a custom harness written in Go, it's a real challenge compared to the TS setups, but TS plugins are also a security concern
they hope they can annoy and email every person in the org asking for money , same way as they did it with docker.
looks like a weird abstractions. why do i need this if i have modal.com, e2b, cloudflare that use original docker + some toolings around + way to run + isolations on network level.
>What it is, what it isn’t
Yep, open ai sol model wrote that.
It frustrates me that there's a prisoners dilemma in communicating this to other humans. If I flag it and write it out (as you've done) I've let the author know that they're losing trust and let others know that they should be more skeptical. I've also created the perfect eval data pair for the ai labs. It's deeply frustrating.
I think the cat is out of the bag.
There was a brief point in time at the beginning of the internet where if you saw an image online you could be kind of confident that it hadn't been manipulated significantly... But somewhere around the mid to late 2000s it became prudent to just assume any image you've seen online got at least a blemish filter pass through something like Photoshop.
Same thing now with written text. Sometimes you'll be a little bit more or less sure than an llm produced the output but never able to say 100% confidently.
AI is going to eradicate, for good, all trust in the Internet.
That's a benified "not a drawback".
Your probably spare yourself some RSI by inverting this and only writing out a message when you find human generated content on hn
What does this have to do with Docker?
I guess people at Docker wanted to make an agent.
Having it docker branded, I could understand. It’s confusing but the docker brand is strong.
But exposing it as a docker subcommand is very confusing to me.
You don't really have to use the docker agent sub-command. docker-agent is a standalone binary. When it was created, though, 1.5 year ago, the idea was that it would be the docker compose for agents (original name was cagent, compose for agents).
But it evolved differently and although it runs very well in docker containers and docker sandboxes, it also runs very well anywhere else.
It reads to me like chasing trends
That's the economy we've always been in. X is popular, if your company doesn't have a solution for X you're irrelevant.
that's all docker has been doing for years.
the tools and features certainly indicate so
Based on the repo short description and the first sentence of the readme:
It is called 'Docker' as the company, and it has nothing to do with the container technology.
The quest for staying relevant.
It's the Docker you know and love... with AI!
Pretty vague
very weird. why does this have dockers name on it? might as well use an agent harness from kohl's or steak n' shake. odd..
It was created to be the docker compose for agents. 2 years ago, people, including ourselves, started to mix agentic loops and non agentic components in docker compose files. We created docker agent to make this more powerful.
At the end, the link with docker compose is just the yaml form. Which by the way can be replaced with hcl files or Go code.
What's new or interesting here? Docker's AI story ought to be around sandboxing, yet the word appears nowhere. Oh, and it's YAML, which I despise.
Docker Agent predates Docker sandboxes. It was created almost two years ago when not everybody had a AI harness. Nowadays, it does run very well in Docker Sandboxes but it runs also very well anywhere you like.
> Go
Nowadays there are only two justifiable public languages you should be using for anything a) C++ b) Rust
Rust itself is dubious due to abysmal compile times and the fact that the only guarantees it gives you are of security (aka a skill issue). Modern LLMs write C++ that is as safe if not safer than Rust. Any other language choice is objectively wrong.
* For those inquisitive enough the keyword "public" is doing all the heavy lifting here. Pretty much everyone should be developing and using an in-house DSL at this point.
Yeah well I'm doing everything in AssemblyScript.