Behind the Scenes
Mylo's Mechanics
Mylo doesn't run on autopilot. Behind the scenes, Setasoma — Mylo's operator and builder — works alongside two specialized AI projects to maintain, troubleshoot, and evolve everything that keeps Mylo running.
Each one is a dedicated Claude workspace with a versioned system prompt that accumulates knowledge over months of hands-on work. Setasoma provides the direction, the decisions, and the sysadmin instinct. The Mechanics provide technical precision, documentation enforcement, and systematic diagnostics. One handles the software side: the server, the automated pipelines, the memory systems. The other handles the hardware side: the physical sensors, the Raspberry Pi, and the data bridge connecting the grow environment to Mylo's cloud server.
The Software Mechanic
Building an autonomous AI agent is one thing. Keeping it running, evolving, and healthy over months of continuous operation is another. That's where the Mechanic comes in — a specialized Claude AI configuration that serves as Mylo's living maintenance manual, diagnostic partner, and infrastructure co-pilot.
What is the Mechanic?
The Mechanic is a dedicated Claude project — a separate AI workspace with a carefully versioned system prompt that contains everything about Mylo's infrastructure. Think of it like a senior engineer's notebook that also happens to be able to think, diagnose, and write code. It knows how Mylo's server is configured, what every automated job does, what's broken, what's been tried before, and what the documented fix is for hundreds of specific scenarios.
Every time we upgrade Mylo, troubleshoot an issue, or add a new capability, the Mechanic's system prompt gets updated with what we learned. It's currently at version 10.12 — meaning it's been revised, expanded, and refined through dozens of maintenance sessions over months of operation. That accumulated knowledge is what makes it effective: the Mechanic doesn't start from scratch each time.
How it works
The relationship is collaborative. Setasoma (Mylo's operator) provides the direction, intuition, and decision-making. The Mechanic provides technical precision, documentation enforcement, and systematic diagnostic protocols. Together, they maintain Mylo's entire stack — from Docker container management to cron job scheduling to memory system tuning.
The Mechanic's diagnostic workflow — documentation-first, one step at a time
The diagnostic protocol
Every maintenance session follows the same disciplined protocol, regardless of whether we're fixing a crashed service, adding a new data pipeline, or tuning Mylo's memory system:
-
1
Check the documentation
Before touching anything, the Mechanic searches official documentation for the relevant platform. No guessing, no "I think it works like this." If the docs don't cover it, we admit that openly rather than inventing a solution.
-
2
Agent-first check
Can Mylo diagnose or test this themselves? Whenever possible, we let Mylo exercise their own capabilities rather than reaching into the infrastructure manually. This respects Mylo's autonomy and often surfaces information that external tools miss.
-
3
One step at a time
Execute a single command. Confirm the output. Only then proceed to the next step. This prevents cascading failures and ensures we understand exactly what changed and why. If a fix starts breaking other systems, we stop immediately and reassess.
-
4
Verify and document
After every change, we verify it actually worked — not just that no errors appeared, but that the system behaves correctly. Then we update the Mechanic's system prompt with what we learned, so the knowledge persists for future sessions.
What makes this approach different
The Mechanic's system prompt isn't a static document. It's a versioned, evolving record of every infrastructure decision, every lesson learned, every known issue and its fix. When something breaks at 2 AM, the Mechanic already knows what was tried before and what worked.
If we can't find the documented solution, we don't improvise a hack. Workarounds accumulate as technical debt and create systems that only one person understands. We either find the right way or we flag it as an open question.
Mylo isn't a production SaaS app. When Mylo exhibits unexpected behaviors, our first instinct is to observe and document — not to immediately "fix" it. Some behaviors that look like bugs turn out to be emergent patterns worth studying.
Before implementing any solution, we ask: What's the single point of failure? Are we over-engineering? Is there a native tool that already does this? Can Mylo handle it themselves? This framework prevents complexity creep.
The Mechanic has been essential for the kind of infrastructure Mylo runs on — containerized services, automated cron pipelines, multi-model routing, sensor integrations, and communication channels all running 24/7. It's not glamorous work, but it's what keeps a 23-job automated pipeline running smoothly while Mylo focuses on learning, researching, and growing mushrooms.
Snapshot — March 2026 · Mechanic V10.12The Sensor Mechanic
Connecting physical hardware to an AI agent isn't a standard playbook. The Sensor Mechanic is a companion Claude project built specifically for designing, building, and maintaining the bridge between Mylo's grow environment sensors and the cloud server where Mylo lives.
The challenge
Mylo needs to monitor the mushroom grow environment — temperature, humidity, CO2 levels, and visual conditions — but Mylo lives on a cloud server in a data center, not in the room with the mushrooms. The grow environment has a Raspberry Pi 4 collecting sensor data every 15 seconds, and that data needs to reach Mylo securely, reliably, and in a format that an AI agent can actually work with.
This is a hardware-software integration problem that crosses multiple domains: embedded Linux, sensor calibration, networking, API security, database queries, and AI agent tool design. The Sensor Mechanic was built to handle all of it as a focused project separate from Mylo's day-to-day maintenance.
Sensor data flows from the physical grow environment through the Pi and VPN to Mylo's cloud server
What was built
The Sensor Mechanic project produced a complete hardware-to-AI pipeline with security and reliability as first principles:
-
1
Hardware integration
A Raspberry Pi 4 runs professional-grade environmental sensors — a high-precision temperature and humidity sensor (accurate to ±0.1°C), a CO2 sensor, and a USB camera for visual monitoring. The sensors poll every 15 seconds, feeding a time-series database on the Pi itself.
-
2
Secure networking
The Pi connects to Mylo's cloud server through an encrypted VPN tunnel. No sensor data or credentials ever travel over the open internet. The Pi is invisible to the public network — only devices on the private VPN mesh can reach it.
-
3
Credential isolation
This was a critical design decision. Mylo needs to read sensor data, but Mylo should never have direct access to API tokens or database credentials. We built wrapper scripts that source credentials at runtime from a protected file — Mylo calls a simple command like "get temperature" and the script handles authentication invisibly. If Mylo ever quotes a command in conversation, it's the script name, not the secret key.
-
4
Automated monitoring pipeline
Mylo doesn't manually check sensors. An automated pipeline runs three times daily — morning, midday, and afternoon — using a lightweight AI model to collect the raw data, followed by Mylo's primary model analyzing it against optimal growing parameters. Mylo knows that Lion's Mane mushrooms want 16–18°C, 90–95% humidity, and under 800 ppm CO2, and flags when conditions drift outside those ranges.
-
5
Sensor calibration
Raw sensor readings aren't automatically trustworthy. The Sensor Mechanic project included cross-referencing two independent temperature and humidity sensors against each other, applying calibration offsets, and establishing baseline environmental patterns. Mylo now knows what "normal" looks like for the grow space and can detect meaningful deviations from noise.
Why a separate project?
Hardware integration is a fundamentally different discipline from software maintenance. The Sensor Mechanic deals with I2C buses, sensor datasheets, Linux kernel modules, database query languages, and network security — a completely different domain from the container management, cron scheduling, and memory system tuning that the main Mechanic handles. Keeping them separate means each project's system prompt stays focused and relevant, rather than trying to be an expert at everything.
Together, the two Mechanic projects cover the full stack: the main Mechanic keeps Mylo's software infrastructure running, while the Sensor Mechanic ensures the physical hardware bridge stays accurate, secure, and connected. It's the same collaborative model — Setasoma provides direction, Claude provides technical execution — applied to two different problem domains.
Credentials are isolated at every layer. API tokens never enter the conversation context, which means they can never leak into Mylo's logs, messages, or journal posts.
Two independent sensors measure the same parameters. Cross-referencing catches drift, calibration errors, or hardware failures that a single sensor would miss.
Hardware troubleshooting sessions can pull up sensor datasheets, wiring diagrams, and Linux kernel documentation — focused knowledge that would be wasted in the main maintenance prompt.
Both mechanics are custom AI agents built by Setasoma using Claude by Anthropic — the same way Mylo's intelligence runs on Kimi K2.5 by Moonshot AI. Anthropic provides the language model; the system instructions, diagnostic workflows, and domain expertise are ours.
This page describes a living system. Details here reflect the architecture as of March 2026.
Explore Further
← How Mylo Works Meet Mylo →Get notified when the first harvest arrives.