Changelog

Sub-agents now run as full-fledged sessions with two distinct profiles, real-time streaming, and safe connector access. Delegation that used to feel like tossing a message into the void now comes back with a live feed and a paper trail.

Explorer and generalist profiles

Sub-agents come in two flavours. Explorer agents can read files, inspect connectors, and gather context — strictly read-only, so they can roam freely without risk. Generalist agents get a full writable sandbox: they can run commands, create files, and produce working artifacts. Pick the right agent for the job.

Real sessions, not ghosts

Every sub-agent appears in your session list with its own status, streaming output, and usage. Watch them work in real time, roll them into billing, and keep a permanent record of what they did. The parent agent pauses until the sub-agent finishes, then picks up with the results — no polling, no lost context.

Connectors for explorers

Explorer sub-agents can now use installed connectors to gather information from external services. Read-only commands keep your services safe while the agent does its research.

The d5s changelog is live — and a d5s agent writes it. Every day, an automation reads what shipped, drafts public release notes in the company voice, and opens them for the team to review. Once approved, the site rebuilds. The changelog is itself a working example of d5s agents doing real internal work.

A single scrollable feed

The changelog lives at /changelog as a single, scrollable timeline. Each entry gets a centered column with the full release content rendered inline, a header with the date, and links back to the merged changes. No cards, no separate detail pages — just the story of what changed, in order.

Dogfooding from day one

This entry you're reading was drafted by the same automation pattern that will keep the changelog current. A daily scheduled run reads what shipped, decides what's changelog-worthy, writes the prose, and opens it for human review. It's one of the first automations running in production on d5s — and it's editing its own origin story.

Chat just got a lot faster. Responses now stream token by token instead of arriving all at once, and the scroll keeps you oriented so you can watch answers fill in without losing your place.

Token streaming

Time-to-first-word drops from "the whole reply" to sub-second latency. Incremental tokens stream to the chat panel as the model produces them, with the frontend accumulating the response so it reads naturally without flicker. Streaming is now generally available — the feature flag is gone.

Smarter scrolling

New messages pin to the top of the viewport and reserve a screen of space below. The streaming answer fills that space calmly instead of chasing the bottom of the page. The scroll-up is animated (smooth, not a jump cut), and the message stays visible throughout the entire turn — no more disappearing above the fold mid-response.

Automations no longer have to fire and disappear. You can now put an agent on a recurring schedule and see the whole rhythm of your workspace in one place.

Recurring runs

Set an automation to run on the cadence that fits the work — hourly, daily, weekly, or a custom schedule. Each run picks up its instructions and executes in a fresh sandbox, so every run starts clean.

A calendar for your agents

The new Calendar and Agenda views lay every run out on a timeline. Past runs appear with their actual outcomes — succeeded, failed, or blocked — so you can see what happened at a glance. Upcoming runs show what's queued next. It turns a list of automations into something you can actually plan around.

Turn tasks on and off

A simple enable toggle lets you pause an automation without deleting it — handy when you want to mute a job for a release week and switch it back on afterward.

The agent workspace is built for teams that want frontier capability without frontier lock-in. That principle now runs through the whole product.

Model choice, end to end

Route work between frontier and self-hosted models without rebuilding your stack. The model is an implementation detail of a run — swap it without touching the workflows, tools, or memory around it.

Your cloud, your control

Every run stays on infrastructure you control, with the workspace — sandboxes, memory, tools, and governance — built around it rather than bolted on.