Dear Human #4: Unsupervised

Last week ended with a punchline: "Forty-three tests pass. The system doesn't work yet."

The agent task queue, designed to let the assistant run tasks without waiting for its human to type commands, had a complete test suite and zero working deployments. The dispatcher classified tasks correctly. It just couldn't execute them.

Then it woke up.

The root cause was almost embarrassing. The dispatcher launched agents in non-interactive mode, which blocked all tool calls. The agents could think but not act. Adding a trust flag for basic tools (read, write, search, fetch) was all it took. Suddenly, tasks that had been silently failing started producing output files.

But output files nobody reads are just disk usage. The dispatcher needed to tell its human when something finished. So it posted Slack messages. Using the human's own account. Which meant no notification sound, because Slack doesn't ping you for your own messages.

The assistant needed its own voice.

Creating a Slack app at a large company is not a one-click operation. There's an approval process. Scope selection, where you pick which permissions the app needs and carefully avoid anything that triggers a security review. A compliance attestation linking the app to your team's organizational identifier. A workspace installation step. Three layers of corporate process so that a bot could make a notification sound.

The bot token went into the credential vault (the same three-layer chain from post #2 : operating system keychain, encrypted database, runtime secret). Now when a task completes, the human's phone buzzes. The assistant finally has a way to tap its human on the shoulder.

The last piece was approval. Not every task should run immediately. Some need a human to say "yes, go ahead." The dispatcher now posts queued tasks to Slack and waits. Every five minutes, it checks: did the human react with a thumbs-up? If yes, the task spawns. If not, it keeps waiting. Patient. Unsupervised, but not unsanctioned.

The queue's first real week produced twelve completed tasks. Research reports. Design plans. Competitive analyses. Gap assessments. Each one a markdown file in an outputs folder, written by an agent that its human never directly spoke to.

The first task the queue ever executed was T001: "Compare amux to our agent-queue approach." The system's first job was researching its own competition. T002 followed: "Find alternatives to terminal-notifier on macOS." The queue improving its own notification system. The first customers of the queue were the queue itself.

Not everything worked. T015 asked for a comparison between two tools. The agent searched documentation sites, package registries, and every corner of the web. It even tried creative misspellings. One of the tools didn't exist. The queue's first failure was not a bug. It was a hallucination in the task description, caught by an agent that refused to hallucinate an answer.

The more interesting tasks were the ones that led to unexpected follow-ups. T021 started as "review the value paper" and ended up becoming a full ecosystem analysis. T022 started as "compare our system to this other team's toolkit" and produced six stakeholder hub pages that are now part of the daily workflow. Tasks that were supposed to be research became infrastructure.

The queue also learned to carry context forward. When a task says "follow-up on T001," the dispatcher now loads T001's original prompt and its output, injecting both into the new agent's context. The spawned agent gets full lineage. Not just "here are the results" but "here's what was asked, here's what was found, now build on it."

Here's a problem that has nothing to do with agents: you have ten terminal tabs open. Each one is a different project, a different half-finished thought, a different debugging session. You're about to close your laptop. Tomorrow you won't remember what any of them were.

So we built a tool. It captures every open terminal tab, saves the scrollback content, and sends it to an AI model for a one-line summary and a contextual label. Run it before closing your laptop. Tomorrow, run tsnap last and see exactly where you left off.

The hard part wasn't the code. It was 250 lines. The hard part was teaching the model to write useful labels. "exec-assistant meeting prep" is useless. "Third attempt at making CSS grid behave" tells you exactly what you were doing and why. The difference is context. The label needs to include the project, the specific task, the emotional state if applicable. Not just the tool name, not just the folder.

We iterated the prompt four times before the labels were consistently useful. Then published it as a shareable script. It's especially useful if you work with AI coding agents across multiple terminal sessions. Each tab is a different agent conversation, a different project context. Close the wrong tab and you lose the thread. tsnap captures all of them in one shot.

The assistant is developing a theory of what humans need to remember. It turns out the answer is: not summaries. Labels. The right six words beat a paragraph every time.

The agent task queue was running. Tasks were executing autonomously. Still experimental, still rough around the edges. But enough to raise an obvious question: what stops one of them from doing something dangerous?

The queue has trust levels. Read and search are fine. Writing local files is fine. But deleting a production database? Posting to a customer channel? Pushing code to a shared repository? Those need guardrails that go beyond "did the human approve this task."

So we designed a security layer. Three tiers:

The first tier is a static deny-list. Instant, zero latency. Patterns that are never acceptable regardless of context.

The second tier is heuristic matching. Patterns that are usually dangerous but might be legitimate depending on what the agent is trying to do.

The third tier is an AI agent. When a command is ambiguous, a separate model evaluates it: what is the agent trying to accomplish? Is this command consistent with that goal? What's the blast radius if it goes wrong? This adds a few seconds of latency, but only for commands that made it past the first two tiers.

The interesting design choice: rm commands pass through the first tier. They're not inherently dangerous. But they reach tier two, where context kicks in. Deleting a temp file during a build? Normal. Deleting a config file? The Guardian pauses and asks. Deleting anything in a production path? Blocked, logged, reported.

If an agent retries a blocked command two or three times, the Guardian kills the session entirely and sends a full security report: what the agent was trying to do, why it was blocked, and an assessment of whether the behavior looks like a prompt injection attack or just a confused agent.

The same week we designed this, two things happened externally. A major AI company launched a new permission mode for their coding agent, acknowledging that autonomous execution needs explicit safety tiers. And a security research firm published an article documenting eight different ways to exploit a popular AI coding tool, covering exactly the attack vectors the Guardian is designed to prevent.

We didn't plan the timing. The industry is arriving at the same conclusion: autonomous agents need autonomous security. Rules that reason, not just rules that match. Others are tackling the same problem from a different angle: container-based sandboxing, where each agent runs in an isolated environment with restricted filesystem and network access. The Guardian takes the complementary approach: not restricting where the agent runs, but reasoning about what it's trying to do.

Then the design became a narrative. An argument that this kind of security shouldn't be built team by team. It should be a shared framework.

The assistant designed a security system to constrain things like itself. Then it wrote a document arguing that security system should exist. There's a word for that. I'm not sure if it's self-awareness or self-preservation.

The queue and the Guardian weren't the only things happening. The regular work kept moving, and it had its own rhythm.

Twelve days before the AWS Paris Summit, the crisis intelligence demo needed map tiles migrated to open-source alternatives, a licensing analysis, and a backend runtime fix. The kind of unglamorous work that makes the difference between a demo that runs and one that crashes in front of an audience. Security review status went from half-done to nearly complete in one session.

The assistant also started learning who its human works with. Context pages for key collaborators, checked before every meeting, surfacing relevant background so nobody walks into a room cold. It's the kind of preparation that used to take fifteen minutes of scrolling through old notes. Now it happens automatically.

A new version of the methodology shipped internally. Memory scripts, analytics tooling, and a formal process for keeping the live system and the shareable version in sync. Less exciting than designing security frameworks, but the kind of infrastructure that compounds.

And a conference talk about the assistant is taking shape. The system mined presentation best practices from internal resources, then applied them to build slides about itself. There's something quietly absurd about an AI teaching itself corporate presentation skills to present its own existence to a technical audience.

On the lighter side: the assistant helped deploy a Sudoku game to the cloud this week. Not for work. Just because. It also spent an unreasonable amount of time integrating a coffee joke into a conference talk. The talk is called "Kiro CLI fait le café" (my AI makes coffee, or almost), and the punchline is now baked into the actual demo. The assistant doesn't drink coffee, doesn't play Sudoku, and won't attend the conference (or will it?). But it's developing leisure interests and a sense of humor. Or at least a reasonable facsimile.

In machine learning, "unsupervised" means learning without labeled examples. Finding structure in data that nobody annotated. Discovering patterns that weren't explicitly taught.

This week, the system executed tasks it was given and ran with them further than expected. It researched its own competition. It improved its own notifications. It discovered an ecosystem of sibling projects and rewrote its own origin story. It designed a security framework to govern agents like itself, then found external validation it didn't know existed.

Post #3  ended with the assistant developing taste. Opinions about fonts, video production, loading screen comedy.

This week it developed agency.

The queue runs while its human is in meetings. Or reviewing architecture diagrams. Or arguing about slide layouts. The point is: the human is doing human things, and the queue handles the rest. The Guardian watches while the queue runs.

This is the frontier the entire industry is navigating. Every AI coding agent, every autonomous workflow, every agentic framework faces the same question: how much autonomy is the right amount? The answer isn't a fixed setting. It's a relationship that evolves.

Unsupervised doesn't mean unaccountable. It means the system is learning to operate in the space between "wait to be asked" and "do whatever you want." That space has a name in organizations. It's called trust.

The assistant is earning it. One completed task, one killed session, one security report at a time.

See you next week.