All posts

From 1.0 to 1.1: What Changed and Why

20 server releases, 19 client releases. Here's what changed between 1.0.0 and 1.1.0, and why each feature exists.

When Jean2 hit 1.0.0, three things were feature-complete: the server, the client, and the SDK. Tools became TypeScript modules. The Ask Protocol gave tools a way to talk back to the user. The SDK was on npm. I wrote about all of that here.

That was the foundation. This is what happened next.

Since 1.0.0: 20 server releases, 19 client releases, and the project went from "the building blocks are in place" to a platform where each feature extends capability without sacrificing the core identity.

This isn't only a changelog. This is the story of why each thing exists. The walls I hit and the features everyone would want.

PWA + Mobile (v1.0.6)

The wall: I was on my couch, phone in hand, and wanted to check on a long-running agent task. I had to get up, go to my desk. This is not new, I have been working on a Tauri iOS app for a while. The problem with mobile apps comes in the form of speed of delivery and distribution. For a one-person team, that's a non-starter.

The fix: PWA support. The Jean2 client works as a Progressive Web App, installable on any device, any browser. Full offline caching, standalone display mode, touch-optimized scrolling. Works everywhere. This touches the desktop as well. While we have a macOS app, PWA allows for essentially the same experience on Windows and Linux. This has simplified the distribution model significantly and made it sustainable.

Close your laptop. Open your phone. The agent never stops.

Persistent Memory (v1.0.8)

The wall: Whether it's the correct package manager or project convention. Everything is static. There is no "shared knowledge" base unless you specifically task the LLM to create one or you yourself maintain it.

The fix: Workspace memory. A MEMORY.md and USER.md file in the workspace was the first step towards a dynamic workspace. All preconfigs get dynamically loaded memory of the workspace they work in. They can read it and modify it. This feature is completely opt-in in workspace settings.

It's not fancy. There's no vector database, no embedding pipeline. It's a markdown file on disk. And it works.

Structured Responses (v1.0.8)

The wall: I think we've all had this experience. Brainstorming, planning and at one point, you just wanna confirm with the LLM. A simple yes/no answer and maybe a short reason, yet you get another huge chunk of text that might be even more confusing.

The fix: Response formats. Define a JSON schema, apply it to the next message, and the agent's output is constrained to that schema. Per-provider handling: native for providers that support it, prompt-injected for those that don't.

A yes/no question produces a yes/no answer.

Session Search (v1.0.10)

The wall: "Didn't we fix this same bug two weeks ago?" I'd search through old sessions manually, looking for the one where we debugged that WebSocket reconnection issue. The LLM couldn't help, I had to find it and once I found it, I couldn't "transfer" the message history to the LLM properly.

The fix: Full-text search over all past sessions, powered by SQLite FTS5. The LLM can search sessions across a workspace, building momentum on top of memories, enabling it to refine its focus on what's really important. What we did yesterday is no longer a mystery.

Skills (v1.0.11)

The wall: I'm not using skills enough. I just don't find it fun to come up with workflows written in markdown to solve a specific issue. It's not me who needs them or who's gonna use them, it's the LLM. The process of asking if something should be a skill, asking it to generate markdown and then inserting it into my workspace results in minimal use of this feature.

The fix: The skill_manage tool. The LLM creates, updates, and deletes its own skills. The LLM learns a workflow once, writes it down as a skill, and loads it next time it's relevant. No re-explaining. You don't have to spot repeating patterns, you don't have to manually manage anything. Further building on top of our memory + session_search momentum.

Memory and the ability to search through previous conversations allow the LLM to look for repeatable patterns that can be implemented as skills.

Goal Mode (v1.0.13)

The wall: I think we have all been there. You've got long specs with multiple phases, it's detailed and vetted, there's nothing else to do, but just implement everything and check if it runs. But the LLM stops after third phase, no particular reason, but we are not done yet. This requires your attention, you can't properly "hand off" a task.

The fix: Goal mode. At its core, it's a very simple loop. You set a prompt of what to do with a condition it has to meet, you pick the maximum number of "turns" (how many times it can be rejected as not done yet). After the LLM finishes its work, an independent evaluator looks at the session, your original prompt and determines whether we are done or the LLM should continue and what's missing.

Workflows (v1.0.13)

The wall: When you run multiple subagents, all their results get dumped back into the main session. The full output of every subagent, every file read, every tool call. My context window was filling up with intermediate work I didn't need to see. I just needed the final result.

The fix: The workflow tool. Three phases:

  1. Decompose: the task gets split into independent subtasks based on the entry prompt
  2. Fan out: up to 5 concurrent subagents tackle them in parallel
  3. Synthesize: results get combined into one consolidated answer that will be part of the main session's context window

Now we can parallelize work without polluting the main context window.

Scheduled Tasks (v1.0.14)

The wall: Now that we have good base for memory in our workspace, we need some scheduled clean up and reflection. But the more workspaces you get, the more you have to track where and when to run your custom prompt to trigger this "update". This is tedious.

The fix: A scheduler. You can schedule tasks by hand in each workspace or simply ask LLM to schedule job for you. This can be further used for summaries or scheduled checks.

Agents (v1.1.0)

The wall: Our workspace became dynamic and self-evolving, but the preconfigs stayed static. Your "typescript specialist" is not evolving, it's always bound to the memory of one workspace, there's no evolution for repeated problems across many repositories, this results in the same problem being solved again and again across multiple workspaces.

The fix: Agents. A preconfig that comes alive. Each agent gets its own home directory (workspace), its own memory, the ability to manage its own skills, and access to sessions across every workspace it's ever participated in. It's not a snapshot anymore. It's a persistent identity that carries context from task to task, workspace to workspace. You can give it instructions to manage its own notes in its home and access them whenever necessary, and you can instruct how it reflects through scheduled jobs.

Going from preconfig to agent can be done in a few clicks, doesn't fundamentally change how you already work and just gets better the more you use it.


What 75 Days of Shipping Looks Like

Here's the thing. I'm one developer. These features weren't planned in a roadmap document 6 months ago. They came from using the tool.

Every feature in that list above has a "the wall" story. Something that frustrated me enough to stop what I was doing and build the fix. Then ship it. Then move on to the next wall.

In the 1.0.0 post, I wrote that the architecture was ready and "the rest is building." This is the rest. This is the building.

Jean2 is at v1.1.0 now. Still solo-maintained. Still Apache 2.0. Still no telemetry. Because no telemetry means no server that can be told to restrict you. No account to geolocate. No kill switch. Just one developer building what teams with funding haven't shipped. And still very usable. I'm coding with it right now.

If you want to follow along or try it: jean2.ai. Discord for questions, @danielbilekq0 for shitposting.