Beneath the Foam

An essay on loomcycle: what it is, why we built it, how we use it, and how we suggest others use it.

2026-10-19 · essay · ~12 min read

1. The foam, and what lies beneath

Most developers have already tried AI-assisted development and seen its upsides. Code gets written much faster, and much better, when the developer actually understands the domain, the shape of the architecture, and the specifics of the SDLC: the workflow, CI/CD, code review, tests. Ten-minute vibe-coded sites and apps have become commonplace. GitHub and the marketplaces are flooded with vibe-coded projects and apps that no one uses. The internet is full of AI-slop articles that nobody reads.

It just happened that AI was easiest to sell when applied to software development. That is the reality of the current AI wave: the surface is covered in foam.

But what lies beneath it?

2. What business wants

Beneath it all are the needs of real business. Real needs for building reliable automated processes and workflows. Business expects AI to actually optimize its internal processes, reduce costs, give visibility and security. Business expects certainty.

Can the current wave of vibe-coding, and the quick build-out of yet more vibe-coding apps, help business and meet its needs? I think the answer is obvious.

Business tries to roll out AI processes through its internal development teams, trying to use whatever solutions are on the market: Microsoft Copilot Studio and Azure AI Foundry Agent Service, AWS Bedrock Agents and Strands Agents, Google Vertex AI Agent Builder and ADK, IBM watsonx Orchestrate. The process is slow and runs into a lot of limitations. There are mindset limits on management and dev teams. There are real security concerns about using API providers. There is just a general mindset gap between existing business processes and what AI could do inside them. There are serious worries that the probabilistic nature of LLMs and the possibility of hallucinations could pose a real risk to business processes.

The era of naive vibe-coding is logically followed by an era of grown-up AI adoption: for live business, for building working apps that have AI at their core. And here we inevitably run into the questions of actually running AI agents in a controlled environment.

However convenient the existing cloud solutions may seem (and they are convenient, nobody is arguing with that), doubts always remain. What does the agent do with your data: send it somewhere, train on it? What does the agent do with your secrets, and how do you give it those secrets safely? Even if the secrets are pushed out to .env or an MCP Vault, who or what stops the agent from pulling them into its context? It does happen, sometimes. A smart agent might notice and ask you to rotate. But it might not. What does the agent do with customer data, with companies' internal data, with medical records, with financial and banking transactions, with personal data under GDPR, CCPA, and similar privacy regimes, with legal documents and NDA-protected materials, with source code and intellectual property?

There is another big question about how and from where agents pull data when they query the internet. For cloud agents, the WebSearch and WebFetch tools sit outside your control perimeter. What prompt injections will they pick up out there, and bring back as hallucinations grounded in untrusted data? How do you control that?

Someone will say: that is the provider's responsibility. Business will answer: that does not work for us.

While building and "deploying" our JobEmber.ai project (deploying is a bit of a joke with 10 real users), we ran straight into all of these limitations.

A lot of questions.

3. What loomcycle is

So, we had our prompts more or less tuned and a rough workflow, and on that basis we built the UI and the agent definitions. Then we tried running the agents through Claude Code, and then through Claude Agent SDK. Neither attempt gave us what we wanted. Mostly because of the low performance of our test VPS: 3-4 agent processes running in parallel were enough to fill up all available memory and CPU.

We looked at the options available at the time, and finding nothing good enough, we started building our own. We implemented the agent loop, the basic tools, and cascaded + parallel agent execution, building it on top of a Unix permissions model.

And it worked.

The application was written in Go, which gave us compactness, low resource demands, and performance. Fairly soon we were able to launch our service running on the newly built agentic runtime, which we named loomcycle: imagining the agents as weaving a single canvas.

We tested the system for stability and performance, and launched the service. It ran without issues for over a month, while we were building the more involved features: authorized MCP access to the API, prompt-injection detection, user personal data redaction, LLM provider routing with user and model tiers.

Someone else might have stopped there. The JobEmber.ai task was essentially solved. But by then, we couldn't stop. The process of building the agentic runtime had turned into a project of its own and started living its own life. We added new tools and refined the agent loop. We connected new local models and taught them to use the built-in toolkit. At some point we realized that agents needed a proper bi-temporal fact memory. Then we added document storage: a fully connected graph of chunked documents, with fast search across multiple parameters. The system kept growing. Each new feature or tool brought its own color and texture, filling in the pattern on the canvas of this project. Our main requirement throughout was security and transparency: exactly what any business needs.

What we have today is a full agentic kernel system, with everything needed for safely running multi-component agentic systems: for safe interaction with the outside world, for storing and quickly searching for whatever information is needed inside or outside, for easy interaction with other systems, and for scaling and cascading. Everything is visible and controllable, both through the UI and through the built-in MCP. All transcripts and audit records can be analyzed both while things are running and after the fact. loomcycle Agentic Kernel works both as a self-hosted tool for one person and as a safe, controllable agentic backend embedded in business systems and cloud deployments.

What that means at the component level.

We built a simple and clear tenants system as fully separated spaces inside loomcycle, in which a tenant can create both isolated users and users who share access to tenant-scope memory and documents. We built a complete Agent Teams system in which system-wide agents, team-local agents, and primitives can interact under a team orchestrator, running predefined and dynamic workflows. We built external A2A, MCP, and Bridge connectors for talking to external systems and user-facing apps like Teams, Slack, and Discord. We built a set of safe built-in bash/gbash tools (thanks to the gbash project), which let agents do file and other operations in safe, ephemeral volumes governed by the kernel and preventing any attempt to escape the controlled perimeter. We built in a headless browser (thanks to the pinch-tab project), in which agents can safely load websites and test web applications. We built dynamic queues for agent access to resource-limited model inference: when 100 agents want simultaneous access to the 16 slots a provider has, no one goes away unsatisfied. Everyone takes their place in the queue and gets their slot by the rules.

And still we didn't stop. Beyond the backend, we thought about the real people who would want to install and use loomcycle. We built LoomBoard, a user-facing multi-platform application that runs on top of the loomcycle backend and brings together different components: a rich-text chat, an agentic team canvas, a task management surface. These components are bundled together into one application, and they are also available as npm components, so you can embed them into your own apps. That is how we built the LoomBoard Chrome Extension, by dropping the loomboard/chat component into it.

4. How we live with it

By now we are actively deploying loomcycle as the agentic kernel backend in our new applications and services.

JobEmber.ai gained a free tier running on our local inference. It is slow, but it works thanks to the queue system: every agent now has a chance to get its inference.

loomcycle is installed on our TrueNAS server, and all project documents have been fully stored in its document storage for several months now. That gives us fast, fully connected search across the entire document graph. On the same server we run the LoCoMo and LongMemEval benchmarks, testing hypotheses and tuning search with decision models. By the way, we recently shipped a Decision tool, through which agents can run the built-in decision models. In general we pay a lot of attention to deterministic processes: this includes both code-js deterministic agents (where a JavaScript program plays the role of the model instead of an LLM) and decision models.

loomcycle runs successfully in the ccq.dglabs.dev project, where it is used for the review, scoring, and audit of code written with Claude Code. loomcycle also runs on loomcycle.cloud together with the LoomBoard UI, and is used in several other ongoing projects.

What does our typical day with loomcycle look like?

We start by designing new features and improving the existing ones. We have a queue of requests from newly launching projects that never empties. For instance, the other day we embedded the go-git library so that code-review agents could safely clone code from a repository into ephemeral volumes, without any risk of getting hold of secrets. From the same wave came a full-featured Crypto tool that supports both local key storage and storage in AWS KMS and Google KMS. In parallel, the external Bridge concept emerged for reaching loomcycle from Teams, Slack, and Discord. All of this comes from real client requests.

We run the implementation in 3-4 threads, each a specialized multi-agent team. Each thread is a feature or a benchmark, then review, then full documentation, then deployment and runtime tests.

More threads just aren't feasible: on top of the automated code review and security audit, we go through every bit of generated code by hand. On a regular basis we do a full module-by-module code review and security audit. Another couple of threads is constantly building and running various benchmarks.

All our documentation and part of our processes, including benchmarks, live permanently inside the loomcycle perimeter and are managed through MCP and the Claude Code plugin. We also have scheduled agents that periodically revisit chats, extract facts into memory, consolidate memory, and build dependencies between documents.

We also collect and distill information about promising work in our own and adjacent fields. That is how we learned about a method for consolidating agent context, which we then implemented as stateful context management: with this method, our chat agents can work even with a 32K-token context without any loss of quality or detail, thanks to the Recall tool.

On top of all that, we shipped n8n community plugins (public and full versions), which let you drop any of loomcycle's primitives and agent teams into an n8n workflow and combine them with other n8n primitives and workflows. We also shipped full-featured connectors to loomcycle via MCP, gRPC, a TS client, and a Python client.

5. What this might mean for you

If you are a developer thinking about a new service that includes AI agents: we are just like you. We have the same concerns and doubts. And we found our answer to them. Now we are sharing our view and our answer. You can try loomcycle in your current or future projects. It will help you close many questions of manageability, security, and transparency when working with AI systems. We are confident of that, because we have tested it ourselves.

If you represent a real business: you almost certainly have doubts and concerns about bringing AI systems into business processes. At the same time, the upsides are obvious to you. We offer you a way to control the risks and, at the same time, get the business benefits of bringing AI in. We are open to working with businesses and to building whatever functionality a business needs. loomcycle enterprise features are on the near-term roadmap. But you can already consider loomcycle a self-hosted alternative today. We will add the necessary user security and observability soon.

We invite you to look at the product and the documentation. The whole product is fully open-sourced under the Apache 2.0 license:

LoomBoard is under active development, so some features may not work completely yet. But the chat works end-to-end and can be used as a standalone component.

The continuously updated project site is at loomcycle.dev, which also hosts the development blog. Comparison tables with similar-in-spirit projects are at loomcycle.dev/vs/.

We really don't have time for active marketing and promotion: we are busy building the product and putting it to use. But the absence of active marketing takes nothing away from its value or its quality.