Idyllic buildlog: Typed conversations

In Restarting Idyllic, I described the kind of agent I want to use: a software system I can talk to, with components beside the conversation that let me inspect and control its work. This week I've been working through how those systems would actually fit into the app. The main design to come out of that work is a persistent conversation for each article, lesson or other thing we're working on, with workflows operating inside it.

A canonical test environment

My September 14 system note described the arrangement I'm trying to build around writing, businesses, learning and the rest of my life. I started mapping those activities into a shared Idyllic workspace so I could work through what each agent would need.

The prototype now brings together Ghostwriter, a Korean teacher, Coursework, Project Upskill, 20cuts, Job Search and a software factory for Idyllic. They are at different stages: persistent chat works, while many of the newer component views still show sample information. I'm using them to decide what the systems should do before filling in all their behavior.

This is also becoming the canonical end-to-end testing environment. The workspace is defined in code, so a script can recreate the agents and their sample material from a known starting point. An ordinary restart retains the work; an explicit reset starts the experiment over. My daily instance keeps separate data.

That lets me develop a scenario through the actual app and then make it repeatable. In Ghostwriter, for example, the scenario can start with source material, produce a draft, receive feedback and retain a revision after a restart. Predictable model responses help test whether the application saves and routes the work correctly. Trying it with a real model and reading the result answers different questions about how well the agent follows the process.

Prototyping Ghostwriter

Ghostwriter gave me the first detailed case because I already know where working with writing agents gets frustrating. Several pieces can be in progress at once. A critique can send one back to research, while another is waiting for me to review a draft. The system needs to preserve the decisions we've made about each piece as different workers contribute.

I worked through those situations in the existing form factor: agents on the left, conversation in the center, components on the right. Putting the draft in the center started turning it into a document app. I wanted discussion to remain the main way I participate, with the draft available alongside it.

The agent overview and the article discussion also needed different things. At the overview, I want to see the pieces in progress and the workers and methods Ghostwriter can use. Inside one article, I want its drafts, research and feedback. Repeating a dashboard inside every article made the interface busier without helping me work on it.

The resulting design keeps a main conversation with Ghostwriter and lets me enter a separate, persistent conversation for a piece.

Proposed Ghostwriter organization: one agent has a main conversation and an optional Pieces set, whose entries are separate work conversations. Workers and saved workflows are shared agent capabilities. — Proposed organization: Ghostwriter coordinates the editorial operation. Each piece keeps a separate work conversation.

Typed conversations

Working through Ghostwriter made it clear that the article is the unit of work that needs to persist. It has a lifecycle, from an idea through research, drafting and review to publication or being put aside. A research assignment or a critique is one contribution to that work. The article can involve several agents and workflow runs before it is finished.

The context for that work includes more than the current draft. A worker revising a passage needs to know what the reviewer objected to, which claims the sources support and what I've already accepted. Those decisions accumulate as the article develops. Keeping them in separate worker conversations would leave me or Ghostwriter to reconstruct how they fit together whenever another worker takes over.

That's why the piece gets its own conversation. In the design I'm working toward, each worker can draw on the relevant history and contribute its result to the same thread, with drafts and research attached to the piece. Several workers may be active at once, but their contributions come together around the work they're helping complete. The thread records the collaboration across them, including my own feedback.

Convergence has a concrete meaning here: the contributions of several agents build toward one result, and the thread keeps the history of how that result developed. I can follow which draft a reviewer assessed, why we changed the argument and what still needs to be resolved. The conversation gives me a way to understand and steer the combined work.

One piece retains a shared history of human, researcher, writer and reviewer contributions, alongside its sources, draft versions, critique and current lifecycle stage. — Research, drafts, reviews and human decisions accumulate around one piece. Workers may run in parallel; the conversation retains their contributions.

This also explains why the conversations are typed:

A piece has an editorial lifecycle, drafts and review decisions.
A job opportunity has a recruiting lifecycle, correspondence and interview preparation.

Both need an ongoing conversation with the context for their work attached, but the useful information and the meaning of progress differ. A type defines that structure and the behavior associated with it.

For Ghostwriter, the component defines a set called Pieces. Job Search uses a set called Opportunities. Each entry has its own history, working material and current state. An agent can have several such sets with different purposes and behavior.

An ordinary agent still starts with one persistent conversation. Extra work conversations come from an optional component. A system helping me with fitness and daily habits may be fine with a single continuing conversation; Ghostwriter needs somewhere to work on several articles independently.

That history can grow much longer than the model's context window. For each turn, the system derives the context to give the model from the conversation's history and working material. Keeping the history and choosing what a worker needs to read are separate concerns.

Workflows and conversation events

The next part is making interaction within these conversations programmable. I'm designing workflows as scripted orchestrations that run inside a conversation and contribute results to it. A workflow could research a question, ask a worker for a draft, request a critique and wait for my feedback.

The article can need several such runs. A research procedure might run again after a critique exposes a missing source. Completing that procedure says the research has returned; it doesn't mean the article is finished. The piece's lifecycle and the execution of a particular workflow have different jobs.

The conversation gives those procedures a place to meet. A review sequence could work like this:

A reviewer posts a critique of the current draft into the piece's conversation.
A configured reaction asks Ghostwriter to assess the critique. If a claim needs evidence, it delegates research using the draft and that specific question.
The research result returns to the same conversation. Ghostwriter can use it to request a revision or bring a decision to me.
My feedback becomes another contribution to the piece's history that subsequent work can use.

A reviewer contribution in Piece A triggers a configured reaction. Ghostwriter chooses a research workflow, which receives relevant material and returns its result to the same Piece A conversation. — Example reaction: a critique prompts more research, which returns to the originating piece. The conversation continues after the workflow finishes.

I find this easier to reason about than coordinating events scattered across services. The event is meaningful in the context of the work: a reviewer has responded to this draft of this piece. The response belongs to a particular piece and draft, and the next worker can be given that material together with the review.

An external service can participate too. A GitHub connector could post a CI result into the conversation for the relevant issue. The configured behavior for that conversation set would determine what follows. Connecting the service still takes work, but the system has a common place to receive its contribution and coordinate a response.

What interests me is computing over a conversation's accumulating history. I can make a particular requirement explicit, such as waiting for my review, while leaving the agent to decide how to investigate a criticism. I don't have to anticipate every editorial decision as a branch in a workflow editor.

The agent as manager

Ghostwriter remains responsible for the broader editorial operation. I can talk to it about which pieces matter, ask where something is stuck or change how I want reviews handled. It makes progress by working with the piece conversations and delegating to workers with the relevant material.

Trying the same distinction in Coursework helped. One version gave each course its own agent, but that meant visiting each one to recover where I was. I preferred one Coursework agent that could help me decide what to study, with separate lesson conversations holding exercises and feedback. A lesson needs its own work history without becoming another agent I have to manage.

Agent components

I'm still refining how components should work underneath this. A component extends the agent's capabilities: it can keep state, expose operations, respond to events and provide a human interface. The card on the right is how I inspect and use that capability.

The components give the agent different capabilities:

Conversations supplies a set of work conversations with configured behavior.
Workflows supplies procedures the agent can run.
Workers supplies the roles it can delegate to.

A work conversation can also have its own components and attachments. A draft may only need a simple viewer; if it lives in Notion, a link to the original may be enough. A live component belongs there when its state or controls help with that particular work. I don't want every attachment to become another miniature application.

The shared component API is still open. Working through these uses is helping define what belongs to the agent, what belongs to a conversation and what several conversations should be able to share.

The discovery loop

The useful part of this process has been getting specific about how I would use each system. A sketch gives me something to react to: where I would begin, what I would inspect when returning, and how I would intervene when the work goes in the wrong direction. That often changes the underlying model as well as the interface.

The loop I'm using is:

Pick an activity I know well enough to judge, and work through concrete moments of using it.
Build those interactions in the shared form factor and revise what feels wrong or is missing.
Add the accepted design to the canonical workspace so it can be considered alongside the other systems.
Implement a reusable component's behavior, exercise it on a real task and try the same capability in another system.

I skipped a fundraising system because I haven't done enough of that work to give useful feedback on the design. Writing and studying give me much clearer expectations to test against.

Typed conversations and workflows are the current focus. I'm working through which contributions should trigger another worker, when the manager should decide what happens next, and what context each participant needs. A reviewer posting feedback on a piece is the next concrete case to define and exercise, then carry over to a different kind of work.