Server 1.0.0. Client 1.0.0. SDK 1.0.0.

All three are feature complete. The building blocks are in place. This post covers the biggest architectural shift since launch: why tools are now TypeScript-only, what that unlocks, and where it points.

The tradeoff: any language → TypeScript

When Jean2 launched, tools were simple. JSON in via stdin, JSON out via stdout. Write them in Python, Bash, Go, Rust, whatever. No dependencies, no runtime requirements. The tradeoff was obvious: maximum flexibility, zero infrastructure.

That model hits a wall. When a tool is an isolated script, it can't talk back to the user. It can't ask for permission. It can't call an LLM. It can't access the workspace safely. Every tool reimplements its own half-solution for things that should be shared infrastructure.

So we made a call. Tools are now TypeScript modules that import from @jean2/sdk. You export a definition and an execute function. The server loads them directly. No child process, no stdin/stdout bridge.

import type { ToolDefinition, ToolContext, ToolResult } from '@jean2/sdk';

export const definition: ToolDefinition = {
  name: 'my-tool',
  description: 'What it does',
  inputSchema: { /* ... */ },
};

export async function execute(input: Input, ctx: ToolContext): Promise<ToolResult> {
  // ctx.fs, ctx.llm, ctx.ask, ctx.env, ctx.logger
}

You lose the ability to write tools in any language. You gain a typed context with file system access, structured logging, environment variable isolation, the Ask Protocol, and the ability to call an LLM from inside your tool.

I don't make that trade lightly. But what it enables is already running in production.

The Ask Protocol

ctx.ask() is a typed channel between a tool and the client. Permissions, questions, confirmations, multi-field forms, all through one API.

const approved = await ctx.ask({
  type: 'permission',
  question: 'Delete files outside workspace?',
  risk: 'high',
  resource: 'file',
  paths: [input.path],
});

const env = await ctx.ask({
  target: 'human',
  type: 'single_select',
  question: 'Which environment?',
  options: [
    { label: 'Production', value: 'prod' },
    { label: 'Staging', value: 'staging' },
  ],
});

This is how the built-in tools handle file permissions, dangerous operations, and user input. The question tool is literally just an ctx.ask() call with rich UI types. The client renders the ask natively. No text parsing, no hacky prompts.

The Ask Protocol also enables client-side automation. A client application can intercept asks and respond programmatically. Auto-approve file reads within the workspace, route deployment confirmations to Slack, batch-approve operations based on policy. The tool doesn't know or care whether a human or a script answered. The channel is the same.

That's the real reason the SDK exists. Not a convenience layer. The foundation for what comes next.

The SDK

@jean2/sdk is public on npm. Two jobs:

Build tools: the ToolContext, typed I/O, Ask Protocol, visualization types
Connect to a server: Jean2Client with WebSocket transport, REST namespaces for sessions, chat, files, terminals, tools, providers, and more

import { Jean2Client } from '@jean2/sdk';

const client = new Jean2Client({ serverUrl: 'http://localhost:8742' });
await client.connect();

client.sessions.create({ workspacePath: '/project' });
client.chat.send(sessionId, { content: 'Refactor the auth module' });

The client, the server, and every tool all speak the same protocol. That's the point.

What this enables

The old tool model was a dead end for anything beyond file operations and shell commands. A standalone script can't call an LLM. It can't ask the user a question. It can't coordinate with other tools. It can't participate in a larger workflow.

The SDK changes that. ctx.llm.generateStructured() gives a tool its own LLM call with typed output. A tool can classify a file, extract structured data from a webpage, decide whether a change is safe. All without the agent orchestrating every step. The tool becomes capable of judgment, not just execution.

That's the building block for things the old model couldn't do:

Computer use: tools that see the screen, decide what to click, and report back structured observations
Browser automation: tools that navigate, extract, and interact with web applications as a first-class capability
IDE plugins: the SDK connects to the server the same way the client does, so your editor can be a full Jean2 citizen
Custom clients: the same SDK that powers the official client is public. Build your own interface, your own automation layer, your own opinionated workflow on top of the same infrastructure

This is the start. The architecture now supports it. The rest is building.

What 1.0 means

Feature complete. All three packages (server, client, SDK) have the building blocks in place for what comes next. The API surface is stable. Backwards compatibility matters now.

Jean2 started as "no baked-in behavior, bring your own everything." That hasn't changed. What's new is that the "bring your own" part has real infrastructure behind it.

Where to start

curl -fsSL https://jean2.ai/install.sh | bash
jean2 init
jean2 start

Or read the Getting Started guide first. The Writing Tools page has everything you need to build your first tool.

Questions, ideas, or something's off? I'm at @danielbilekq0 or Discord.