Back to journal

Product note

Governed agents instead of vague automation

Autodeck separates assistants, specialists, and workers because different kinds of AI work need different permissions, expectations, and runtime behaviour.

Governed agents instead of vague automation

One of the fastest ways to make an AI product feel impressive in a demo and unusable in production is to hide every behaviour behind the same assistant surface.

The result is familiar:

  • a chat box that seems to do everything
  • no clear distinction between advice and execution
  • no stable expectations around permissions
  • little understanding of what happened after an action runs

Autodeck takes a more explicit approach. It distinguishes between three agent roles because the product should tell the truth about how work is being done.

Assistant, specialist, worker

The split is simple on purpose.

Assistant

An assistant is a synchronous advisor.

It explains, guides, clarifies, and helps a user work inside a Deck. It should feel close to the interface and close to the user's current task.

Specialist

A specialist is also synchronous, but it is much closer to the actual product flow.

This is the right shape when the AI is not merely helping around the edges but is part of the main interaction model for a domain.

Worker

A worker is background execution.

This is where longer-running or non-conversational tasks belong. A worker should not pretend to be a chat reply when what it really is is a governed job with inputs, outputs, and runtime state.

Why the split matters

This is not taxonomy for its own sake. The role split makes the rest of Autodeck more coherent.

It clarifies:

  • what the user should expect from the interaction
  • how permissions should be applied
  • when approvals are required
  • what should be streamed live and what should run asynchronously
  • how actions should appear in logs and audit trails

In other words, the product becomes easier to operate because it stops pretending every AI action is the same kind of thing.

Decks are where this becomes visible

In Autodeck, users normally encounter these agent roles inside a Deck.

A Deck combines:

  • the visible working surface
  • the relevant model lane
  • the toolset for the domain
  • the agent role that makes sense for that kind of work

That is much stronger than bolting a generic assistant onto every page and hoping the user will infer what is safe, what is authoritative, and what is actually happening.

Less magical, more trustworthy

There is a reason many AI products prefer ambiguity. Ambiguity feels smooth at first.

But the moment teams care about repeatability, auditability, or shared responsibility, ambiguity becomes friction.

Autodeck would rather make the operating model visible. That means less theatrical "AI magic", but much better odds that people will trust the system when the work actually matters.