Why Docket Bet on
Custom Cognitive Architecture
to Power AI Agents

Why Docket Bet on
Custom Cognitive Architecture
to Power AI Agents

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. 

Cognitive Architecture: Your Real Edge In A Commodity LLM World

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.

Why Legacy Chatbots Can’t Serve Answer-First Buyers

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.

The Thinker–Responder Pattern: Designing The Mind, Not Just The UI

If you've read Kahneman, you know the idea:

  • System 1 is fast, intuitive, always on. Pattern matching. Gut reactions.
  • System 2 is slow, deliberate, expensive. It kicks in when things get hard and you need to actually think.

The Thinker–Responder pattern maps cleanly onto this.

The Responder: Fast, Buyer-Facing System 1

The Responder is the “mouth” that handles the conversation. It’s always on, managing routine interactions:

  • Maintains tone and voice
  • Handles clarification questions
  • Accesses short-term memory
  • Decides when it can answer directly vs. when it needs to escalate

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:

  • Tone control – change the voice (“professional”, “playful”) without touching the reasoning layer
  • Policy filters – run responses through PII / compliance checks before they go out
  • Channel reuse – one Thinker can power multiple Responders across web, email, Slack, internal tools

From the user’s perspective, the Responder is “the agent.” 

The Thinker: Deliberate System-2 Reasoning

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:

  1. Qualify the lead against ICP criteria
  2. Check if they exist in the CRM
  3. Find the account owner
  4. Book a meeting on their calendar

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:

  • Log every plan for compliance
  • Block plans that violate policy before they run
  • Require human approval for high-stakes actions
  • Audit what the agent intended to do, not just what it did

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.

The Tool Registry: Governed Capabilities for Your Agents

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.

Custom Cognitive Architecture vs “GPT + Tools”: Why Architecture Wins

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.

Extensibility: Compose, Don’t Rebuild

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).

  • Add a tool → multiple agents gain a new ability.
  • Add a Thinker → you get new reasoning behavior without touching the rest.

For example, add a single tool like routing.assign_owner_and_book_meeting, and overnight:

  • Your website agent can route high-intent visitors and book AEs
  • Your SDR assistant can do the same mid-call
  • Your partner agent can do it for partner leads

You’re composing systems, not rebuilding bots every quarter.

Data Governance: Plans, Not Blind Shots

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:

  • The Thinker first produces a plan
  • Policies, guardrails, and even a separate “guardian” layer plug into that plan
  • Only allowed plans hit the Tool Registry

You get a structural place to say “no” before anything touches real systems.

Control: Architecture Beats Prompt Patching

Want different behavior for:

  • high-value accounts vs free users?
  • EU vs US?
    staging vs production?

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:

  • Swap or tune Thinkers by segment or environment
  • Change tool bundles per tier, region, or risk profile
    Keep the same Responder but change how the brain behind it reasons

Why We’re Sharing This (And What’s Next)

We believe all the enterprise applications have to take some form of this architecture to make sure the agents we build are: :

  • Safer by design
  • Smarter over time
  • Extensible without rewrites
We're not keeping this private. We want more teams to build agents this way. Because the field doesn’t need another vague ‘AI agent’ diagram, it needs something concrete people can use as a foundation to build on. For us, this architecture is the bicycle for the next era of enterprise intelligence.

And we’re just getting started.
Arjun Pillai
Founder & CEO, Docket Inc