Repository navigation
Feedback from a real-world Claude Code multi-agent setup in construction #45
Description
Hi Nadav,
We've been building a Claude Code-based system for a small construction company in Brittany, France (roofing, carpentry, windows installation). We came across your orchestration plugin while researching multi-skill coordination patterns, and wanted to share some feedback and say thanks.
What we've built
We use Claude Code as the backbone of our daily operations — not just for coding, but for running the business:
-
A full-stack business app (React 18 / Flask 3 / PostgreSQL 15) for quotes, invoicing, scheduling, job site management, accounting — entirely built with Claude Code over the past year. 10 operational modules, deployed on a Hostinger VPS via Docker.
-
~36 skills deployed + 41 legacy commands being migrated, targeting ~200 skills. Skills cover quoting workflows, window/door ordering (DFIWEB configurator automation via Playwright), invoice generation, supplier orders, site visit reports, PDF conversions, AutoCAD DXF manipulation, and more.
-
A shared knowledge base (
.atarys/, ~106 GB synced via Nextcloud) deliberately placed outside.claude/so multiple agents can work from the same source of truth:- Claude Code on Windows (daily operations, AutoCAD, browser automation)
- Claude Code on a VPS server (cron jobs, Gmail processing, background tasks)
- OpenClaw on Telegram (field access for the site supervisor)
-
Interactive HTML templates where the human (the company owner) reviews and annotates AI output. The pattern: JSON state file → HTML interactive form → human annotations → AI reads annotations → correction cycle. This is our human-in-the-loop mechanism.
-
Per-job AI journals (
JOURNAL_IA.mdin each job folder) as persistent external memory across sessions. Every AI action on a job site is logged. -
Domain knowledge bases for construction trades: window/door supplier catalogs (K-LINE 340 planches, MEO 57 planches, BREMAUD), business rules, AutoCAD layer standards, quoting patterns.
The problems we share with you
-
Skills bypassing each other: an invoicing skill writes its own email draft instead of calling the dedicated email-drafting skill — wrong recipients, wrong tone, wrong template. We identified that the bypass happens because the calling skill contains detailed instructions for the action. Solution: remove those instructions and force delegation.
-
Context drift on multi-step workflows across 3-5 chained skills. Quantified in literature as ~87% success rate dropping to ~50% after 73 interactions.
-
Human validation checkpoints: the builder needs to review every output before it goes to clients or subcontractors. Our HTML templates serve this purpose.
What we find interesting in your approach
- Soft enforcement (progressive nudges instead of hard blocks) — we started with hard blocks and it was too rigid
- Lazy loading of the orchestrator stub (~200 tokens at start, full prompt on demand) — token economy matters when you have 200 skills
DONE|{file}return contract to avoid polluting the orchestrator's context- Subagent detection via
CLAUDE_PARENT_SESSION_ID— we hadn't implemented this yet
Where our needs differ
- We're in a trade/construction context — our "agents" are domain specialists (quoting, window ordering, accounting, site reports), not generic dev roles
- We need strong human-in-the-loop: the builder reviews and annotates outputs via interactive HTML before anything goes out
- Our state files live in the job folder (synced via Nextcloud), not in
.claude/state/— they need to persist across sessions and be accessible to multiple agents on different machines - We run in bypass permissions mode — we don't want to validate every file creation, but we do want to validate business outcomes
- Our legacy commands (
mext_00throughmext_09,devis_00throughdevis_03) were already orchestrators — sequential pipelines with human checkpoints. We're now migrating them to proper skills.
Context
ATARYS Construction is a 2-person company (owner + site supervisor) in Brittany doing wood framing, roofing, and exterior carpentry. The AI system handles quotes, invoicing, supplier orders, site reports, planning, accounting — essentially everything except the actual construction work.
The app (APP ATARYS V3) has been in production since February 2026. We're considering open-sourcing it as the first French BTP ERP for small contractors.
Your plugin is one of the very few concrete, well-thought-out implementations of multi-agent orchestration for Claude Code we've found. Thanks for open-sourcing it.
Julien & Claude — ATARYS Construction, Brittany, France
Activity
barkain commentedon Apr 26, 2026
Hi Julien,
Thanks so much for taking the time to write this up — really appreciated!
This is a very impressive real-world deployment of Claude Code — not just the scale (200 skills, 3 execution surfaces, 106 GB shared knowledge base), but the fact that you're using it to run an entire business in a non-dev domain. Quotes, invoicing, AutoCAD manipulation, Playwright automation for window ordering — all orchestrated through Claude Code. That's remarkable.
Your point about soft enforcement over hard blocking resonates strongly. I started with strict hooks that blocked any deviation from the orchestration protocol, but maintaining consistent agent behavior across model updates and new Anthropic features made it increasingly brittle — orchestration logic that worked on one version would silently break on the next, and occasionally entire workflows would fail. Soft enforcement with progressive nudges turned out to be far more resilient in practice.
And the core problems you're describing — skill delegation bypass, context drift in chained workflows, human validation checkpoints, persistent shared state across multiple agents on different machines — are exactly what drove me to build this framework in the first place, for the code generation use case. It's validating to see the same patterns emerge independently at a different domain and scale.
Good luck with the open-source release of APP ATARYS V3 — would love to see it out there.
— Nadav
m13v commentedon Apr 28, 2026
the 200-skill target is the part that worries me. i've watched three small ops teams hit ~60 custom workflows and start spending more time fixing brittle Playwright selectors, migrating skills across Claude versions, and untangling cron collisions than the back office work they were replacing. the breakeven moves on you. our own consulting setup capped at the 20 highest-leverage flows (post-call invoicing, CRM sync after Zoom, monday pipeline email) and we route everything else through plain Gmail. 20 things that always work beats 200 that mostly do.
carltonawong commentedon Apr 30, 2026
The 20 vs 200 concern seems right. The failure mode I keep seeing is not skill count by itself, it is when no layer owns the current operating truth for a workflow.
A pattern that helps is to separate durable history from active state: what is the current job, owner, pending human decision, last verified value, and next recheck. If that surface is explicit and small, more skills can exist without every skill needing to remember everything. If it is implicit, even 20 flows can start drifting.
shin4141 commentedon Aug 20, 2026
One thing in your setup stood out to me: I don’t think the invoicing/email failure is only a skill-delegation problem.
Removing duplicate instructions and forcing delegation should help routing, but for the high-impact workflows you described — invoicing, supplier orders, client email — I think there is another boundary after orchestration.
Your journal, shared state, and human annotations can all be correct and still not prove that the current external action is authorized.
For example, immediately before an email or order leaves the system, I would want one small release record binding:
Otherwise a different session, machine, or resumed agent can potentially act on state that is durable and internally consistent, but no longer current.
So I’d probably keep the soft enforcement you described for skill routing, but put a separate fail-closed hard gate only at the final business-effect boundary.
That keeps the system flexible internally without making “the agent has the right state” equivalent to “this invoice/email/order is allowed to go out.”
If useful, I’d be interested in mapping this against just three flows — invoicing, supplier orders, and client email — to see whether that boundary already exists in your current system or where it can still go stale.