There's a Steve Jobs quote I keep coming back to:

"I think one of the things that really separates us from the high primates is that we're tool builders. I read a study that measured the efficiency of locomotion for various species on the planet. The condor used the least energy to move a kilometer. Humans came in with a rather unimpressive showing, about a third of the way down the list.
But then somebody at Scientific American had the insight to test the efficiency of locomotion for a man on a bicycle. A human on a bicycle blew the condor away, completely off the top of the charts."
Humans aren't particularly fast or strong or efficient. But give us the right tool—something as simple as a bicycle—and we outperform everything else.
I operate in the enterprise B2B space. In the AI world, I think a lot about how humans interact and get work done as individuals, squads, teams and cohorts. There are three elements we use every day to keep moving our work and companies forward:
Reasoning: Use our brains to understand the scenarios, objectives, resources, and make decisions in a logical order.
Communication: Whether to coordinate with our team to keep people informed, we use communication methods and channels (text, voice, videos, slides and other artifacts along with languages). Communication is also key for taking feedback and adjusting.
Tools: We use the right tools for the job, whether it is a computer or internet or ChatGPT to get the job done.
If we are building agents that operate in enterprise workspaces which operate and get things done like humans, we need to capture the same model.
When we set out to build Docket, we knew we had to replicate that fundamental model: reasoning, tools, and communication working together. That’s when our AI agents can truly empower enterprises.
Here's the reality: large language models (LLMs) are commoditized. Everyone has access to frontier models from OpenAI, Google, Anthropic. The “ingredients” are available to everyone.
So why do some AI systems deliver value while others hallucinate and break?
Same reason your favorite restaurant makes better food than everyone else with the same ingredients. It’s not the flour or the tomatoes. It’s how they put it together. The technique. The system. And how they tweak the recipe based on feedback from every plate returned.
In AI, that system is your cognitive architecture. It’s how your agent reasons over time, manages memory, uses tools, adapts to feedback, and decides when to think deeply vs respond quickly.”
We built Docket on a specific pattern called Thinker–Responder (known in research as Reasoner–Talker). We're making this blueprint public because we think it's the right way to build reliable, safe enterprise conversational agents.
But first, we have to bury chatbots.
The first generation of business AI was rule-based chatbots. Decision trees in a chat bubble. They could click you through FAQs or reset a password, but they couldn’t reason about your actual situation.
Post-ChatGPT, users didn’t want flows. They want answers to their scenario, right now.
That's why the future isn't "better chatbots." It's agents that can actually think, talk and act.
But here's where most teams stumble: they try to make one LLM call and do everything at once. Understand the user, plan the action, call the API, write the response—all in one step.
That's too much cognitive load. It gets messy.
And messy in enterprise means dangerous. When reasoning and execution blur together, you can't audit what happened, block risky actions before they run, or even explain why the agent did what it did.
The Thinker–Responder pattern fixes this by splitting the agent into two distinct systems, mirroring Daniel Kahneman’s System 1 and System 2 thinking.
If you've read Kahneman, you know the idea:
The Thinker–Responder pattern maps cleanly onto this.
The Responder is the “mouth” that handles the conversation. It’s always on, managing routine interactions:
It doesn’t call your CRM. It doesn’t touch systems of record. When a task needs deeper reasoning, it hands off to the Thinker.
That gives you a clean separation between talking and doing. When those blur together, you lose control. You can’t see what’s about to happen. You can’t intervene before damage occurs.
Because the Responder is separate, you also get:
From the user’s perspective, the Responder is “the agent.”
When the Responder encounters something complex—"Qualify this lead and book a meeting with the right rep"—it hands off to the Thinker.
The Thinker is the brain.
First, it builds a model of the task. What's the goal? What's the current state? What's unknown?
Then it creates a multi-step plan:
Next, it selects the specific tools it needs and executes the plan, handling errors and edge cases as they arise.
Finally, it updates shared memory so the Responder can explain what happened.
The key: the Thinker produces a plan before it executes.
That plan becomes a choke point for governance. You can:
You can't achieve this when reasoning and execution are mashed into one opaque LLM call. The Thinker–Responder split gives you inspectability by design.
Humans don’t grow new limbs every time they need a new capability. They pick up a new tool. Agents should work the same way.
At Docket, tools are managed centrally in a shared Tool Registry. Each agent is provisioned access to only the tools it needs. The Thinker never has raw, free-form access to your systems; it can only act through approved capabilities like crm.update_lead or calendar.book_slot.
The upside is simple and powerful: extensibility.
Add a tool → the agent gains a new ability.
You don’t rebuild the agent. You just hand it a new tool.
It’s tempting to say: “We plugged GPT into some APIs. We have agents now.” On the surface, that looks similar to what I’ve described. Under the hood, it’s not.
A custom cognitive architecture gives you a few things “GPT + tools” rarely does.
GPT + tools usually means: One model, one mega-prompt and a handful of tools bolted on. Want new behavior? You edit the giant prompt. Again. And again.
With a cognitive architecture, tools live in a central registry. You mix and match Thinkers (reasoning), Responders (channels), and tool bundles (capabilities).
For example, add a single tool like routing.assign_owner_and_book_meeting, and overnight:
You’re composing systems, not rebuilding bots every quarter.
In GPT + tools, the model decides what to do and does it in one go. If the prompt gets jailbroken and calls a tool, it is already too late.
In Thinker–Responder:
You get a structural place to say “no” before anything touches real systems.
Want different behavior for:
In a GPT + tools world, your main lever is: “Add more instructions to the giant prompt and hope the model listens.”
With a cognitive architecture you can:
We believe all the enterprise applications have to take some form of this architecture to make sure the agents we build are: :
.png)