Restarting IdyllicI want to run a writing pipeline or software factory without reconstructing its progress from chat.

I'm rebuilding Idyllic solo in 2026, after a hiatus. The earlier project ran from April 2024 through December 2025. Since then, using AI for writing, coding and business experiments has made the problems I want to solve clearer.

I've also become more convinced by the Bitter Lesson: general methods that benefit from more computation tend to outperform carefully encoded human knowledge. I'm comfortable leaving more decisions to the model. I want to build an environment where I can see its work and change how the system operates.

What I like about Grokbot

Grokbot felt like it finally got the interaction right: a persistent agent with one continuing thread. I can describe what I need, create a bot and start talking to it. When I return to writing, I know which conversation to open.

I especially like how composable it is. I can create a group chat of bots, bringing together agents I already talk to individually. That scales naturally in the way human communication does: when work involves more people, we bring them into the conversation. I want to keep that simplicity as the systems behind those conversations get more capable.

The writing pipeline

When I want to create an agent for writing and get really specific about how it works, skills don't seem to carry it far enough. I'm talking about a whole editorial pipeline: taking an idea, enriching it with research, critiquing the draft through multiple passes and bringing me in for review.

That's hard to encode in a skill, and it's hard to verify. The skill is Markdown. I can write down how the process should work, but then I have to run it and inspect the traces to see what actually happened. Once several agents are involved, I also have to follow how their work fits together and whether the coordinating agent is managing them the way I intended.

I don't want to build that in Zapier or n8n. I hate working in those workflow editors. Defining an editorial process that way is extremely difficult, because the next step depends on what comes back from the work. A critique might call for more research or another revision; my review might change what the article is trying to say. I don't want to draw out all of those decisions as a workflow.

What I want is the flexibility of an agent with a system around it that I can inspect. Parts of the editorial process should have their own visible state and controls, so I can manage the process of the agent managing its workers. I shouldn't need another prompt just to see which draft is being reviewed or where work is waiting on me.

Seeing and controlling the process

I want to see the machine in motion without having to reread the instructions and reconstruct the process from its traces every time. I expect to stay involved, like a captain aboard a ship that's already running. I can check with the engineers, inspect the hull or go to the bridge and adjust the course while the machinery keeps operating.

For the writing system, I want to be able to:

• Open the draft that's waiting for review and leave feedback, while independent research continues.
• Inspect the research a worker has returned before using it in the article.
• Change which article the system should work on next.

I can still talk to the agent when I want to discuss the direction or explain a change.

Agents as software systems

An agent, in this design, is a software system I can talk to. The writing agent might coordinate several research and critique workers internally, but I can manage the editorial process through one continuing conversation.

Creating another top-level agent adds another system for me to oversee. That gives me a practical way to decide where a new capability belongs:

• A review queue belongs inside the writing agent as a component. It extends the editorial system I'm already managing.
• A separate business operation can have its own agent because I want to return to it and direct its work independently.

An internal worker doesn't automatically need its own entry in my sidebar.

Software factories

The discussion around software factories often makes the setup sound complicated. Some people describe it as skills and a queue; others show systems whose internal workings I don't know. I find it easier to reason about the development process itself:

1. Someone encounters a problem and records it as an issue, perhaps in Linear.
2. A coordinator routes the issue to a worker, with the relevant context from shared notes or a specification in Notion.
3. The worker makes a change and explains what it did in a pull request.
4. GitHub CI runs checks, and a reviewer assesses the change before it can be merged. Feedback can send it back for more work.

People still decide which problems matter and whether the resulting changes solve them. Code can enforce required checks and review before merging, while an agent decides how to investigate the issue and implement a change.

In Idyllic, I'd want that whole operation to be the agent I talk to. I could start with a software project, then add the queue and worker setup it needs as I develop the process. Its coding agents would be participants inside the system.

The components could supply the supporting machinery:

• A queue would hold work and its current status.
• Skills and memory would retain the procedures and project decisions workers need.
• A cache could keep results that would otherwise have to be retrieved again.
• Herdr instances and computers would provide places for workers to run.
• Connectors would let the system use an existing service where that makes sense.

Cloud computers are part of that direction; the current application runs locally.

Agent components

Idyllic's layout puts agents on the left, the selected agent's conversation in the center, and its components on the right. Each component has a live card that opens into a fuller application.

An agent component is a small application with saved state and behavior. It exposes operations to the agent and an interface to me; both use the same underlying state.

The bundled components already include:

• Journal: keeps records we can both inspect and supplies entries as context.
• Computer: provides a Linux computer we can both operate.
• Herdr: manages worker and terminal sessions, including work the agent delegates.

I considered dividing the sidebar into separate sections for tool integrations, routines and other kinds of extensions. For now, I'm keeping it as a simple collection of cards. Each component should have few dependencies and expose operations the agent can combine. I'll add more structure when using the app, or watching someone else use it, gives me a reason to.

The SDK

There are already useful terminal tools and installable skill packs for coordinating agents. I want to package those capabilities so I can work with them without continually watching the agent's terminal. Command output often tells me what the agent is executing without giving me a useful overview of the work.

The design gives an agent its own persistent computer, where it can keep files and use installed software. The SDK lets a developer connect a capability to a small reactive app in the sidebar.

I think of the backend as an OS-like environment for these components. A plugin needs a way to retain its state and respond to events after any particular model turn has ended. Its human interface can stay live between model turns.

For a queue, the agent and the card should read and change the same work records. When a worker finishes, the queue updates its record and the card receives the new status. Changing a priority in the card updates the record the agent will read next. Neither side has to reconstruct a separate version from chat.

A connector can still use MCP or another service underneath; the component provides the retained application and controls around it.

What I'm trying next

The local app already supports persistent conversations and attaching bundled components. A basic Workflows component now keeps run history and can pause for human review. Its steps currently generate text in sequence; the more adaptive editorial process above is what I want to build on top.

The experience I'm aiming for is assembling an agent from components. I could choose them myself, perhaps by dragging them into place, or ask the agent to choose what it needs. After a little configuration, I'd start using the system and refine it through conversation.

For example, I could tell the writing agent to put drafts in the review queue before revising them further. I want it to remember that arrangement, so I don't have to explain the relationship between those components in every session. Automatic component selection and remembering how they should work together are still part of the design; today I attach the bundled components myself.

Writing will give me a system to use daily and something concrete to show other people. I want to watch which components they reach for and where they still need to ask the agent to explain what's happening. Those attempts should tell me what to make visible next.