If you have ever watched a team of AI agents do good work and then been unable to say which one did the useful part, guilds.run is built for exactly that moment. This self-hosted, open-source multi-agent workflow audit tool from CigaleAI finished fifth on Product Hunt’s October 12 daily board with 162 votes, on one promise: every step of a multi-agent run can be audited backwards, fixes start as drafts, and nothing ships until you hit publish. Verdict up front: if you are a developer shipping agent workflows you might one day have to defend to a client or a compliance officer, guilds.run is the most practical trust layer we have seen this year. If you are a non-technical team looking for a polished hosted service, it is not for you – yet.
What it does
guilds.run is a local-first platform for building and running teams of AI agents – “guilds” – where each agent has its own task and its own model. A research agent might run on a cheap fast model while the code-review agent runs on a frontier one. The product’s real differentiator is not orchestration, though. It is what happens after the run.
Every run is recorded as a fully inspectable trace. You can see the exact prompt each agent received, every tool call it made and the result that came back, every change to its memory, and the group chat between agents. When a run goes wrong, you do not get a shrug and a log file. A built-in feature called Studio reads the run, finds the cause, and drafts a fix – as a draft. Nothing in your workflow changes until you review and publish the fix yourself. That publish gate is the whole product thesis: agents do the work, humans hold the pen.
It is also deliberately self-hosted. The entire thing runs on one machine with Docker, your API keys are encrypted with a key that lives in a local .env file, and the code is open source on GitHub under CigaleAI. For teams handling sensitive data – and we build a lot of internal automation for clients who would never put customer data through a third-party agent cloud – that architecture is the feature.
How a multi-agent workflow audit tool earns its name
The October 12 Product Hunt board tells the story of where agents are heading. Six of the top ten products were agent infrastructure, and the theme Frontier Now’s write-up identified was the shift from “does it run” to “does it have data, memory and an approval chain.” guilds.run was the board’s explicit trust play: its audit trail and publish gate are the human-signature answer to an agent that does real work.
Here is the failure mode that makes auditability non-optional. One agent makes a wrong assumption. Another takes it as fact. The shared notes absorb it, and the error compounds through the team. More instructions do not fix that – seeing what actually happened does. A recent engineering write-up on multi-agent auditing put it well: when agent A plans a fix and agent B applies the edits with the write credential, you need a handoff receipt, not a shared trace. “Somewhere in the log” is not an operational answer to “who changed this and why.”
guilds.run answers exactly that question. Because each agent’s prompt, tool calls and memory changes are attributed separately, you can reconstruct who produced a specific output, whose session held the credential when a write happened, and where an untrusted instruction entered the chain. In our experience building agent workflows for clients, this is the conversation you have with every serious stakeholder about week three of a project – and most teams discover they cannot answer it. Having the audit trail from run one instead of bolting it on after an incident is the difference between a demo and a deployable system.
Getting started: three commands
Installation is genuinely simple for a developer audience. You need Docker with the Compose plugin, git, and bash. The images include a browser and coding tools for your agents, so have free disk space ready.
- Clone the repo:
git clone https://github.com/CigaleAI/guilds.git && cd guilds - Run setup:
./setup.sh– this creates the.envfile holding the encryption key for your stored credentials, and builds the sandbox server plus the agent runtime image. It takes several minutes the first time, then printsReady. - Start it:
docker compose up --detach --wait, then openhttp://127.0.0.1:8080in your browser. - Connect a model provider when the welcome dialog asks – guilds.run is bring-your-own-model, not a model reseller.
- Set up a guild: create agents, give each its own task and model, and hand the team a real task.
- Inspect the run: drill into prompts, tool calls, results, memory changes and the agent group chat.
- When something breaks, ask Studio why. It reads the run, finds the cause and drafts the fix. Review the draft, then publish – the fix goes live only on your approval.
Per the official install docs, the box starts with a single user – “operator” – in one organisation called “Home”, and anyone who can reach the address on that host is that operator. Remote access for a team is a separate setup step worth reading before you expose it. And keep the .env file: nothing else has a copy of the credential encryption key, so losing it means re-entering every key.
Pricing
Here is an honest answer: at the time of writing, guilds.run publishes no SaaS pricing tiers on its launch page or docs, because it is not really sold as SaaS. It is open-source software you host yourself. The real cost model has three line items you control directly: the machine it runs on (modest – one box with Docker), the disk and compute for the agent runtime images, and your LLM API bills, which depend entirely on which models you assign to each agent and how much work they do.
That is both the upside and the trap. You are not paying per seat for features you do not use, and there is no vendor margin on your tokens. But there is also no one to absorb a runaway agent loop – a misconfigured guild hammering a frontier model can burn real money while you sleep. Set per-agent model choices conservatively, use cheaper models for routine steps, and treat the audit trail as your spending receipt too. If your team needs a vendor contract, an SLA and compliance paperwork, look at enterprise alternatives instead (see below).
Who it is for
- Developers and small teams shipping agent workflows who need to debug why the team did what it did, not just whether it worked.
- Agencies and consultancies whose clients will eventually ask “who changed this and on whose authority?” – which, in our experience, is every serious client by week three.
- Teams with data-residency concerns – everything runs on your machine, credentials are encrypted locally, and no agent cloud sees your prompts.
- Builders iterating fast – the draft-fix-then-publish loop is a genuinely good workflow for tuning agent behaviour: propose, review, approve, repeat.
Watch-outs and honest limitations
guilds.run launched on Product Hunt in mid-October 2026, which means it is weeks old. The audit and publish-gate design is sound, but longevity, update cadence and security patching are all unproven. That is not a reason to dismiss it – every tool was new once – but do not hand it production credentials on day one. Run it against staging, keep the agents’ permissions tight, and promote access gradually.
- Single-operator default. Out of the box there is one user and no team roles. If you need per-person permissions and an org audit log of who approved what, this is not that product yet.
- Heavy first install. The agent images bundle a browser and coding tools, so the initial build is slow and disk-hungry. Fine on a dev machine or a small VPS, annoying on a thin laptop.
- Audit data is only as complete as the instrumentation. Prompts, tool calls and memory changes are captured – but if an agent does something meaningful through a side channel the platform does not mediate, the trail has a gap. Understand the boundary of what is logged before you treat the audit as a compliance record.
- Launch-day attention is not staying power. 162 votes and a fifth-place finish measure launch-day interest, not production reliability. We could not find independent third-party reviews yet – treat vendor claims as claims.
How it compares to alternatives
The multi-agent tooling space splits cleanly into three lanes, and guilds.run sits firmly in one of them.
Enterprise agent control planes like Guild (a different company – do not confuse the names) sell governance for production fleets: SSO, per-agent credentials, budgets and audit across LangChain, CrewAI and custom agents, with SOC 2 paperwork for the security review. That is the product you buy when the CISO is in the room. guilds.run is the product you run on your laptop when the developer is debugging at midnight. Different buyer, different budget, different question.
Human-in-the-loop approval layers such as withHuman, which we reviewed earlier, add an approval step to agents you already run elsewhere. guilds.run goes further – the whole run environment plus the audit trail – but demands you adopt its platform. If you are happy with your orchestration and just need a human gate, the lighter approval layer wins. If you are starting from scratch and want debugging plus governance in one box, guilds.run is the fuller answer.
Framework-native observability – traces and dashboards from the agent frameworks themselves – tells you what happened at the API-call level but rarely attributes handoffs between agents cleanly, and almost never drafts the fix. guilds.run’s Studio loop (diagnose, draft, publish) is the step up from passive logging to active correction. For teams whose agent workflows live inside broader workflow automation, that correction loop is what turns a brittle pipeline into something you can hand to an operations team.
From our experience
We build AI automation for clients across nine-plus years and three hundred-plus projects, and the pattern we keep seeing is this: teams buy the agent framework first and discover the trust problem second. Someone asks for the audit trail in a stakeholder meeting, nobody has one, and a month of retrofitting begins. guilds.run’s core insight – that the audit trail and the approval gate should be day-one infrastructure, not a bolt-on – is exactly right. It matches how we scope client work: before we automate a process, we define who approves what and what the receipt looks like. A tool that makes those receipts the default is a tool that shortens every discovery conversation.
Two pieces of practical advice if you try it. First, do not let the publish gate become a rubber stamp. A fix you approve without reading is just an agent action with extra steps – schedule a real review, especially for changes that touch permissions or prompts. Second, back up that .env file on day one. It is the only copy of the key that encrypts every credential the box stores, and “we lost the .env” is a surprisingly common way to lose an afternoon.
Frequently asked questions
Is guilds.run free?
The software is open source and self-hosted, so there is no licence fee or seat cost. You pay for the machine it runs on and for your own LLM API usage – the per-agent model choices you make determine most of the bill. There were no published SaaS pricing tiers at the time of writing.
How is this different from the logs my agent framework already gives me?
Framework logs record API calls; guilds.run attributes work per agent – exact prompts, tool calls and results, memory changes and the agents’ group chat – and then goes further with Studio, which diagnoses failures and drafts fixes that only go live when you publish them. It is the difference between a log file and an audit system.
Do I need Docker experience to run it?
Enough to have Docker with the Compose plugin installed. The documented path is three commands – clone, ./setup.sh, docker compose up – and the app opens at http://127.0.0.1:8080. The first build takes several minutes because the agent images bundle a browser and coding tools.
Can non-technical teams use guilds.run?
Not comfortably, yet. It is a developer tool: Docker-based, bring-your-own-model, single-operator by default. Business teams that need a managed service with team roles and an SLA should look at enterprise agent platforms – or talk to an agency that runs this kind of infrastructure for you.
Who should not use it?
Anyone running a single simple agent probably does not need a multi-agent audit platform. And if you need formal compliance evidence today – SOC 2 reports, vendor contracts, per-user audit logs – a product this young cannot carry that weight. Revisit in six months, or buy the enterprise lane.
Bottom line: guilds.run is the rare launch that understood the assignment. Multi-agent systems do not fail for lack of models – they fail for lack of answers to “who did this and on whose authority.” A multi-agent workflow audit tool that is self-hosted, open source and honest about its publish gate is a strong foundation. If you are evaluating AI automation for your business – agents, workflows or the audit story around them – talk to us. We build this stuff for a living, and we will tell you straight whether a tool like this fits your stack or not. Browse more hands-on reviews in our AI Tools Directory.