A penny for your context?
Welcome back to the PrettySmart show after a week on Vancouver Island exploring what may be the most laid back part of Canada I've witnessed yet: Tofino, British Columbia. This week on the show we have several very different but long-awaited new pieces in awman: Experimental support for Docker Sandboxes, initial integration with GitHub Issues, and something I'm quite enamoured with called "context overlays".
Starting with that last one, context overlays allow agents to share context and state with one another without affecting the repository they're working on. Passing --overlay context(repo) attaches two things to a running agent: a durable directory shared by any agent who has run in that repo, and an appended system prompt that explains to the agent where to find it and what to do with it. Agents can share notes, useful scripts, gotchas, artifacts, or whatever else they need to get smarter working on your project. context(global) is universal for all agents, regardless of repo, and allows you to share things like personal preferences, code styles, special rules you want them to follow, etc. Think about things you personally want your agents to do but isn't universal enough to commit to a CLAUDE.md shared by a team at work.
The one that blew me away though, is context(workflow). When you have a bunch of agents being executed one after another as part of an awman workflow, each one needs to start from scratch and do an expensive exploration of the repo to determine what's been done, and gets absolutely no context about what was tried and/or failed in previous steps. Now if you pass context(workflow) to awman exec workflow or set it in the workflow's new overlays field, every agent in that workflow run gets a shared context directory and a dynamically generated system prompt that explains to them what workflow they're a part of, which steps have run, which step is currently active, what's still to come, and how to use the context directory to share information.
Using context(workflow), I witnessed agents reading and writing notes for each other, writing a script for a later agent to use to validate behaviour of a rust crate, and picking up information about questions I answered for an agent in a previous step when clarification was needed. It seemed to seriously improve agent coordination across a long-running workflow and it's no enabled for every workflow I use across awman and ane. Now on to the rest!
# install or upgrade
curl -s https://prettysmart.dev/install/awman.sh | shawman gains experimental Docker Sandboxes support
Docker shipped Sandboxes (sbx) earlier this year: a standalone tool that boots real microVMs with their own kernel, filesystem, and Docker daemon for running coding agents in yolo mode. awman now experimentally supports sbx as as a third runtime alongside Docker and Apple Containers:
awman config set --global runtime docker-sbx-experimental
awman ready
awman chatThe new runtime is tagged -experimental on purpose since sbx itself is young and doesn't yet have all the flexibility of containers, so it's opt-in and clearly labelled. Not everything will work perfectly, and not all features of awman are supported just yet, but it's an excellent start and works really well! One nice property of Sandboxes is that they are persistent. Each project only needs to bootstrap each agent's microVM one time, and every later launch just restarts the existing VM. There's a long Runtimes guide covering credentials, kits, and the known limitations (Linux is blocked upstream for now).
One main limitation to note is that the sbx kit autogenerated by awman when launching a Sandbox does not currently have all of your project's tools (language toolchains, etc.) automatically installed as it does with containers (defined by your Dockerfile.dev). A coming release will figure that out, but for now your agents will need to install tools themselves while you experiment.
From issue to spec to PR, without the copy-paste
The other big quality-of-life change in v0.10 is GitHub Issues integration. Most work starts as an issue of some kind, and until now you had to copy that issue into a work item file by hand. Now there's a --issue flag on the three commands that take input:
awman new spec --issue 84 # generate a spec from the issue, augmented by your agent
awman exec workflow implement.toml --issue 84 # run an awman workflow against an issue, no file needed
awman exec prompt "review the implementation plan" --issue 84 # include an issue's description as context to a promptPassing an issue number resolves against your repo's GitHub remote, owner/repo#84 and full URLs work too. awman uses gh if it's installed and authenticated or falls back to direct API calls if it isn't.
Making workflows more autonomous
On the workflow side, workflow definitions can now wait on CI results. A new poll_ci step type monitors the Github Action for the current branch/PR/commit and does not proceed until they are all complete and green (up to a certain retry count). Paired with that, any setup or teardown step can carry a new on_failure block with a defined prompt that launches an agent to fix an issue autonomously. If a make test step fails, an agent is launched to fix them before a commit gets pushed. This functionality is still early but it quickly getting better and will become even more flexible in future releases.
Also in this release
Your project base Dockerfile no longer has to be named Dockerfile.dev, you can configure your project's base Dockerfile path in the repo config file. awman also now honours XDG_ env vars when selecting its config and data directories. Agent running inside a container/sandbox via the awman TUI now receive scroll-wheel events, and you can finally select and copy text out of the execution window. Full details in the release notes.
Source and issues at github.com/prettysmartdev/awman. More at prettysmart.dev. Feedback, issues, and contributions all welcome.