← Selected work

Agentic systems · Workflow architecture · GTM

GTM Operating System: Radical Frictionlessness

What does it take to move from scattered AI use cases to one connected operating system?

Company
Honeycomb
Period
2026
Disciplines
AI Architecture, Agentic Systems, Workflow Design, GTM
Chapters
8
1
Connected operating architecture
100+
GTM tasks mapped into it
4
Autonomy levels defined
01The situation

GTM had real AI usage. People were getting value in chat windows and then pasting the output somewhere by hand. Every win stayed local, and the effort of moving information between systems ate most of the gain.

02The actual problem

The request was

Roll out more AI tools to the GTM team.

Discovery showed

More tools would have added more copy and paste. The friction was between the systems, not inside them. Context lived in Notion and Salesforce, conversation lived in Slack, and the model had access to neither at the moment it was needed.

The goal I set was radical frictionlessness: the work reaches the right person or agent with the context already attached, and the result writes back where the next step happens. That is an architecture problem, not a licensing one.

03What I learned
  • Mapped where GTM context actually lives and which systems can read and write it.
  • Traced handoffs to find the points where information was retyped rather than passed.
  • Tested MCP connections and skills against real tasks before committing to a pattern.
  • Set autonomy levels per task class so write-back never outran trust.
04How I framed it

Exhibit

The Operating Architecture

01Surfaces

Slack and Cowork, where the work is already being discussed

02Agents & skills

Reusable skills per task class, with defined autonomy

03Context (MCP)

Notion, CRM, and data sources connected as first-class context

04Write-back

Results land in the system of record, not in a thread

05Notifications

The next human is told, with the reasoning attached

Write-back is what turns a helpful answer into a completed step.

What you're looking atEach layer earns its place by removing a handoff a human was doing manually.

Exhibit

Autonomy by Task Class

 Context neededWrite accessHuman role
01Draft and summarizeThread + docsNoneReviews output
02Assemble and enrichCRM + NotionScoped writeSpot checks
03Route and notifyOwnership mapWrite + notifyHandles exceptions
04Commit a changeFull recordAudited writeApproves first
What you're looking atAutonomy is granted per task, not per tool, and it moves up only with evidence.
05What we built
  • 01An MCP-connected context layer so agents read from the real systems of record.
  • 02Reusable skills for recurring GTM task classes rather than one-off prompts.
  • 03Write-back and notification paths that close the loop into Notion, CRM, and Slack.
  • 04Autonomy levels tied to task class, with evaluation before any level increase.
06My role
Architecture
Designed the connected system and chose the integration patterns.
Build
Configured MCP servers, skills, and write-back paths hands on.
Adoption
Worked inside GTM workflows rather than shipping a tool and leaving.
Guardrails
Defined autonomy levels and the evidence required to raise them.
07The outcome
  • AI moved from isolated chat sessions into the GTM workflow itself.
  • Handoffs that used to require a human copying context now carry it automatically.
  • New use cases plug into existing context and write-back instead of starting from zero.
  • Autonomy became a decision with criteria rather than a preference.
08What I'd do differently

The interesting engineering was not the agents. It was the plumbing that let them see the truth and change it safely. Nobody demos plumbing, and it is the entire difference between a pilot and an operating system.

Contact

Let's get into it.

Ambiguous problem, AI adoption that stalled, an operating model that stopped scaling, a support function that should be a product. That is the conversation I want.