How I Think About Agents in Product

Agents are getting framed like autonomous coworkers. That framing is exciting and often misleading.

My framing is simpler:

An agent is a workflow with memory, tools, and risk.

The core agent loop

Most useful agents execute some variant of:

1. observe context
2. decide next step
3. act via tool
4. report outcome
5. update memory/state

If you can’t describe your loop this clearly, you don’t have an agent system yet.

What separates toy agents from production agents

Production agents need:

• explicit permissions
• bounded action spaces
• approval gates for risky steps
• complete event logs
• rollback mechanics

Without these, you get automation theater plus operational anxiety.

Agent architecture choice I recommend first

Start with a single-agent orchestrator + deterministic tools before multi-agent choreography.

Reasons:

• easier debugging
• clearer ownership
• lower coordination overhead
• fewer emergent failure modes

Multi-agent only pays off once single-agent constraints become the bottleneck.

Memory should be designed, not improvised

There are three memory layers I like:

1. session memory (current task)
2. working memory (recent patterns/preferences)
3. durable memory (explicit approved facts)

Conflating these is a common source of weird behavior.

What to measure for agents

• task success rate
• supervision load (how often humans intervene)
• error severity distribution
• recovery time after failure
• user trust trend over repeated usage

This tells you whether the agent is helping or creating hidden labor.

Final stance

I’m bullish on agents. I’m just allergic to magical thinking.

Treat agents like junior teammates:

• define scope,
• instrument behavior,
• review outputs,
• coach continuously.

That’s when they become genuinely useful.