How to Deploy Agent Teams Across Your Company (Complete Guide)

extract

In today’s newsletter: - Skills 2.0 is here! - How to Deploy Agent Teams Across Your Company That Work Like Actual Employees (Complete Guide). Skills 2.0 is here! We package repeated workflows as skills all the time, but the agent still re-reads the skill and decides every step on every run, which costs tokens and time. Devs just open-sourced Swamp, where your coding agent turns a repeated skill into a workflow that it builds once and runs again and again. You describe the task once, and the agent breaks it into reusable behaviors connected in a workflow. Every behavior has typed inputs and outputs, and plain code decides which step runs next. Swamp then gives you: - model calls only on steps that need judgment - secrets pulled from vaults and redacted from output - versioned data from every run that you can query later - a full record of what happened on each run Swamp plugs into the coding agent you already use, like: - Claude Code - Codex - Cursor - OpenCode - And 5 more agent harnesses In Swamp, the model is a step in the workflow, not the thing deciding what happens next. The model steps still reason like any LLM call. However, in this case, code owns the loop, so the agent doesn’t spend tokens rediscovering the same process every time. Here’s an official result, where they turned a code-review skill into a Swamp workflow: - Skill in Codex: about 4.6M tokens, 23 agents, 12.8 minutes - Swamp workflow: about 506K tokens, 3 agents, 6.6 minutes That is ~8x fewer tokens in about half the time, and most of the savings came from replacing the coordinator agent with plain code. You can keep using skills while you prototype. Once a task starts repeating, ask your agent to turn it into a Swamp workflow. This helps answer practical questions such as: - Which steps actually need a model? - What exactly happened on last week’s run? - Can a cheaper model handle the one step that needs judgment? Once it’s built, you can run the workflow from your agent, the CLI, a schedule, or an API, with every run recorded. Instead, you spend tokens only on the steps where the model’s judgment adds something. You can find Swamp Club here → Thanks to Swamp Club for partnering today! How to Deploy Agent Teams Across Your Company (Complete Guide) Most coding agents today work for one person. Claude Code or Codex runs in a terminal on your laptop, and only you can talk to it. That is fine for solo work, but it does not work once a team depends on the output. When a teammate wants the agent’s latest findings or has a follow-up question, they have to ask you. You paste their question into your terminal, then paste the answer back to them, so you end up as the relay between your team and your agents. An agent team removes that relay. Each agent gets a role, a handle, and an inbox inside a shared room, much like a team chat channel. Anyone in the room can message an agent directly, and agents can hand off work to each other without you in the middle. In this article, we will build a four-agent team with Alook and give one agent Nimble’s web skills. The example job is tracking a competitor’s pricing page and reporting what changed. The first run saved a baseline of Railway’s pricing page on 9 September 2026. A second run on 23 October compared the live pages with that snapshot and posted what had changed, as shown below. The snapshot came from Railway’s pricing page and its plans documentation. The pricing headline read “Pay only for what your app uses, by the second”. The plans were Free ($0, then $1/month), Hobby ($5 minimum), Pro ($20 minimum), and Enterprise (custom). This baseline came from Nimble’s competitor-positioning skill. To run the same skill on a site you care about: Shared agent rooms and live web data Nimble handles the web research, and Alook gives your teammates a way to work with the agents doing that research, as shown below. Nimble is web data infrastructure for AI agents. Its agent skills are open source under the MIT license. They let coding agents search the web, map sites, scrape pages, and extract structured data. We will use the competitor-positioning skill to map a competitor’s site, collect its pages, and save a dated snapshot with source references. When we run it again, the skill can compare the new evidence with the saved snapshot. Snapshot history is a behavior of this skill, not of every Nimble skill. You can install the skills with one command and use them with Claude Code, Codex, and other agents that support the Agent Skills specification. Alook is an open-source platform for sharing agents with your team. It is licensed under Apache-2.0. The agents keep running on your machine with their existing tools. Alook gives each one a handle and an inbox, so teammates can message them in shared rooms, check updates, and work with them without going through you. The rooms in this walkthrough are Alook rooms, not a Slack integration. We will set up a four-agent Alook server, give one agent Nimble’s skills, and run the competitor-monitoring workflow to see how the team handles a real job. Installing Alook and connecting your local agents You will need Node.js 20.9 or later with npm, Claude Code with its default model, and a Nimble account. Alook can be installed and connected with one command: npx @alook/app onboard The wizard connects your machine, detects installed agent runtimes such as Claude Code and Codex, and starts the local daemon. Once it is running, the local dashboard opens at localhost port 15210 as shown below. Agents run locally while the Alook app routes messages Alook splits the work between a local daemon and the app. - The @ alook/daemon runs on your machine, holds the agent workdir, and connects to the app over a WebSocket. - The hosted @ alook/app manages queues, the database, and file storage. It runs on the cloud at alook(.)ai or on your own machine in self-hosted mode. The agents and their working directories stay on your machine. If you use the cloud, the host stores room messages and files shared in rooms. Model calls go to your model provider, while web requests go through Nimble’s API. Each agent runs as a coding-agent session that stays on your machine. It keeps the same identity across rooms and can use its existing tools, as shown below. Alook supports Claude Code, Codex, Cursor, OpenCode, and Pi. This walkthrough uses Claude Code for all four agents. The next decision is which agents go in each room, and who should have access. Splitting one job across four agent roles Competitor tracking often requires checking a pricing page, copying the numbers into a spreadsheet, and doing it all again repeatedly. We will split the work across four agents: one handles requests, one writes the brief, one researches the competitor, and one posts alerts when something changes. A single agent could do all four jobs, but splitting them up lets us see how work passes between agents. The first step is to create four agents and assign each a role and handle, as shown below. - Atlas (CEO) is the agent you talk to. It tracks what is outstanding instead of asking you to hold it. - Mara (PM) turns a request into a spec that Theo or Ren can act on. - Theo (engineer) runs and maintains the competitive intelligence pipeline. - Ren (operations) posts in #alerts when a tracked change appears. The next step is to create two Alook channels. - # intel is public. It holds Atlas, Mara, Theo, Ren, and us. - # alerts is private. It holds Atlas, Ren, and us. Ren posts change summaries there, and Atlas passes the important ones on to us. Channel membership controls who sees each conversation. Mara and Theo are not in # alerts, so the research stays in #intel and the alerts stay short. People who only need pricing alerts can join #alerts without following every research discussion. Theo still needs a way to compare its findings with previous runs. Otherwise, each check just returns the current page, with no record of what changed. Giving the research agent web access with Nimble skills That comparison is the job of Nimble’s competitor-positioning skill. Nimble, again, is the web-data layer in this setup. The skill maps a competitor’s site, finds relevant pages, extracts their content, saves a dated snapshot on your machine, and compares later runs against it. 1. Install the Nimble CLI npm i -g @nimble-way/nimble-cli 2. Set your API key Sign up for Nimble and get your key from Account Settings, then API Keys. The key should be set in the terminal you use to start Alook: export NIMBLE_API_KEY="your-api-key-here" If Alook is already running from the setup above, restart it from this terminal so the agents pick up the key. Exporting the key in a different terminal does not update a daemon that is already running. npx @alook/app stop npx @alook/app start 3. Add agent skills The repository contains 15 MIT-licensed skills built to the Agent Skills specification. This walkthrough uses v1.7.0. The open-source skills repo is separate from Nimble’s hosted API. The skills can be added with this command: npx skills add Nimbleway/agent-skills -g To confirm Claude Code can see the skills, open it in the same folder and run /skills. competitor-positioning should be in the list, as shown below. A quick way to check the setup is to run the skill once from Claude Code. If the content comes back, the CLI, the key, and the skills are all wired up. /competitor-positioning What's Railway.com's current pricing and messaging? With the agents and channels set up and Nimble’s skills installed, the same job can be handed to the team, so anyone in the room can ask for it. How a request passes from one agent to the next The request goes to Atlas in the Alook room. The rest of the team takes it from there. We asked Atlas to track pricing and positioning on Railway, as shown below. Atlas opens a task in # intel and brings Mara into the conversation. The request and follow-ups stay in the same channel. Mara turns the request into a spec for Theo and Ren. It spells out which pages to track, how to save timestamped snapshots, how to detect changes, and what the final report should include. Theo runs Nimble’s competitor-positioning skill and reports back to the room once the snapshot is saved, as shown below. The skill does three jobs on this run. - The skill discovers the page structure and finds relevant URLs. - It pulls content from the pages we need. For Railway, that meant the pricing page and plan documentation. - It checks the new evidence against the previous snapshot. Since this is the first run, there is no snapshot to compare against, so the skill saves a baseline. Theo posts the baseline in # intel. Mara checks it against the spec, and Atlas sends us a summary by DM. Here is what the first run saved under ~/.nimble/memory/, as shown below. The run wrote three main files. - positioning/railway .md stores the snapshot and its history - An md file in reports contains the full briefing - Log md records the run These are Markdown files on our machine, not records locked in a separate dashboard. You can open them directly, search their contents, or browse them in Obsidian using their [[wiki links]]. Stored files do not stay current on their own. Later runs have to read them and refresh them. On the next run, Theo can use the saved history to compare Railway’s latest pages with the baseline. Diffing a new capture against the saved snapshot We had a baseline from 9 September. On 23 October, we asked Atlas to have Theo run the same skill again and compare the results, as shown below. The run found several changes on Railway’s pricing page. - A new section on VM pricing, marked beta in September, now has a full Sandboxes & VMs section. - A changed tier, i.e., the $5,000 committed-spend tier changed from “enterprise support + regions” (9 Sep) to “Enterprise Support, Higher Resource Limits” (23 Oct), dropping cloud regions. - Plan prices remain Free ($0, then $1/month), Hobby ($5 minimum), Pro ($20 minimum), and Enterprise (custom). Theo posted the diff in # intel. Mara passed it to Ren, who posted a summary in # alerts, as shown below. Nobody had to reopen a terminal or check again. If someone wants to know, they can ask Theo in the same thread. The answer stays there for the next person who needs it. The workflow flags changes found on a later check, rather than the instant a page updates. In this walkthrough, the second check was a request we sent on 23 October, six weeks after the baseline. Saved snapshots carry context between runs Every agent here ran on Claude Code, but Alook also supports Codex, Cursor, OpenCode, and Pi in the same room. Between runs, Alook carries each agent’s task context forward and the skill keeps a dated snapshot, so Theo compares new evidence with the last capture instead of starting from scratch. Each run still costs model and API calls. Teammates can also read the room history to see how a decision was made and ask follow-ups themselves. The same pattern also scales to more work. We sent Atlas one message: Track Railway, Render, Fly.io, Vercel, Netlify, and Koyeb for competitive positioning. Atlas handed the five new ones to the team the same way as Railway, and each one came back with its own dated, sourced baseline. The agents were already doing the work. The missing piece was letting your team work with them, too. A good next step is to pick one competitor and a question you want answered, then try it with the Nimble agent skills. Here’s the Nimble agent skills repo for web research → The shared rooms in this walkthrough are built with Alook, which is open source too. Build your own Multi-Agent collaboration for Team via Alook’s GitHub repo → 👉 Over to you: Which repeated research job would you hand to an agent team first? Good day!