# Pulse > Pulse is the company brain. It indexes the work that actually > happens (Slack threads, PRs, tickets, docs, meetings) and turns it into a > permission-aware graph of decisions, commitments, owners, and open questions > that you can ask, navigate, and act on. Pulse is built and operated by Pulse HQ (legal entity: Pulse, Inc.). The public site is https://pulsehq.tech. ## What Pulse does - Indexes work across 25 connectors: Slack, GitHub, GitLab, Notion, Linear, Jira, Asana, Monday, Trello, Confluence, Google Drive, Dropbox, Airtable, Miro, Google Calendar, meeting transcripts (Zoom, Otter, Fireflies, Granola), Salesforce, Zoho, Apollo, Stripe, Microsoft 365, Canva, Gmail, and Clay. Read-only by default. ACLs from the source tool are mirrored at retrieval time, not filtered after the fact. - Extracts decisions, commitments, action items, and the people who own them as first-class entities, not just searchable strings. - Answers questions across all of the above with sentence-level source citations and a calibrated 0 to 100 confidence score per answer. - Drafts the work that should happen next (108 action kinds across 21 systems: Linear tickets, Slack DMs, Salesforce updates, Gmail drafts, calendar invites) and lands every one in an approval inbox before anything ships. - Auto-extracts reusable Skills from observed work so a team can codify "how we run a launch" or "how we triage a P1" without writing prompts by hand. ## Who Pulse is for Teams of 5 to 500 people. The sweet spot is any team that has outgrown one Slack workspace, accumulated three or four different sources of truth, and wants a memory layer that respects existing access controls rather than a chat box that ignores them. ## Core differentiators - **Process graph, not document index.** Pulse models decisions, commitments, PR reviews, and meeting outcomes as typed entities with relations between them. A document index returns pages; Pulse returns the decision, who made it, what informed it, and what still depends on it. - **ACL mirroring at retrieval.** Slack channel privacy, Notion page sharing, GitHub repo permissions, and Drive file ACLs replicate into Pulse's ResourceAcl table during sync. Every retrieval call passes through a visibleDocumentIds gate. If you can't see a thread in Slack, you can't see it in Pulse. - **Calibrated confidence.** Every answer carries a 0 to 100 confidence score that is calibrated per workspace and per topic from your team's thumbs-up/thumbs-down feedback. Low-confidence answers are flagged as such and can escalate to a named human expert on the team. - **Approval-gated agent actions.** Every external write (Slack DM, Linear ticket, calendar invite, doc comment) passes through an inbox first. Five minute undo on most of them; create-only writes with no clean upstream delete are flagged non-revertible up front. Allowlist enforcement on recipient domain, channel id, repo name, and team key. - **No training on tenant data.** Pulse uses Anthropic Claude, OpenAI, and Google Gemini under API terms that bar training on the traffic sent (inputs may be retained briefly for abuse monitoring). Per-tenant isolation enforced by mandatory tenantId filtering on every query. BYO Anthropic key, Google Gemini key, AWS Bedrock, or Azure OpenAI supported on Enterprise. - **Auto-extracted Skills.** Observe a few runs of a recurring task and Pulse compiles the pattern into a reusable, reviewable SKILL.md. Skills promote through DRAFT, SHADOW, ACTIVE: shadow mode scores each Skill against what the team actually did, and only a clearing match rate activates it. ## What Pulse is not - Not a doc search box. Pulse can search, but search is not the product. - Not a chatbot wrapper. Pulse can answer, but the value is the decision graph and the approval-gated actions that hang off it. - Not a generic RAG layer. Pulse models work as typed entities, not just chunks. - Not a surveillance tool. There are no productivity scores, no keystroke logs, no "manager dashboards" that rank people. The audit log records what Pulse did, not what you did. ## Integrations live today (25) Slack, GitHub, GitLab, Notion, Linear, Jira, Asana, Monday, Trello, Confluence, Google Drive, Dropbox, Airtable, Miro, Google Calendar, Meeting transcripts (Zoom, Granola, Fireflies, Otter), Salesforce, Zoho, Apollo, Stripe, Microsoft 365, Canva, Gmail, and Clay (push-in webhook). Writes are a separate opt-in consent per connector, and every write is approval-gated. ## Skills and MCP Pulse follows the Anthropic Agent Skills standard. SKILL.md tarballs work in Claude Desktop and Cursor. Pulse also runs a native MCP server with 27 tools: 15 read tools (search_company, get_decision, find_expert, get_pulse, pulse_ls, pulse_grep, plus nine more), 7 capture tools (pulse_capture_conversation, pulse_capture_snippet, pulse_capture_decision, pulse_capture_commitment, pulse_capture_failure_case, pulse_capture_note, pulse_suggest_skill), 3 personal-memory tools (pulse_remember, pulse_recall, pulse_forget), pulse_propose_action, which drafts real actions into the human approval queue and never executes anything itself, and pulse_propose_config, which turns a plain-language setup request into a config proposal (a custom entity type, decision, feature, glossary term, or process) for the same approval queue. Clients connect with an API key, a per-user MCP token, or a full OAuth flow (dynamic registration + PKCE). The REST surface includes GET /v1/documents (filterable + CSV export) and GET /v1/learnings, both keyset-paginated and ACL-filtered to the calling key's user. GitHub connects as a GitHub App, minting per-install tokens so sync survives the connecting user leaving. ## Product - [Home](https://pulsehq.tech/): the company brain for teams of 5 to 500. - [How it works](https://pulsehq.tech/how-it-works): the index, the process graph, permission-aware retrieval, and approval-gated actions. - [Features](https://pulsehq.tech/features): the full capability map across Home, Ask, Map, People, Agents, Outputs, Skills, Voice, and MCP. - [Why Pulse](https://pulsehq.tech/why-pulse): the case for team AI over individual chatbots. - [By role](https://pulsehq.tech/use-cases): role-shaped views for founders, eng leads, PMs, ops, and ICs. - [Pricing](https://pulsehq.tech/pricing): plans and the individual single-seat tier. ## Platform and developers - [Integrations](https://pulsehq.tech/integrations): the 25 connectors and how permission mirroring works. - [MCP server](https://pulsehq.tech/mcp): connect Claude, Cursor, and ChatGPT to your workspace memory over MCP. - [API reference](https://pulsehq.tech/api): the REST surface for pushing documents and proposing actions. - [Network](https://pulsehq.tech/network): publish and fork Skills and Playbooks across the Pulse network. ## Trust and data handling - [Security](https://pulsehq.tech/security): isolation, encryption, audit log, BYOK, and the certification roadmap. - [No-surveillance position](https://pulsehq.tech/no-surveillance): the things Pulse will never do, signed. - [Manifesto](https://pulsehq.tech/manifesto): the product principles in writing. - [Privacy](https://pulsehq.tech/privacy): how customer data is handled. - [DPA](https://pulsehq.tech/dpa): the data processing addendum and subprocessor list. ## Compare - [Pulse vs Glean](https://pulsehq.tech/vs/glean): enterprise search versus a decision graph. - [Pulse vs Notion AI](https://pulsehq.tech/vs/notion-ai): in-Notion authoring versus cross-tool memory. - [Pulse vs Coworker AI](https://pulsehq.tech/vs/coworker): two takes on team AI. ## Cornerstone essays - [Team AI vs individual AI](https://pulsehq.tech/blog/team-ai-vs-individual-ai): why shared memory beats per-person chatbots. - [Process graph vs document graph](https://pulsehq.tech/blog/process-graph-vs-document-graph): modeling work as entities, not pages. - [The 5 to 500 software team segment](https://pulsehq.tech/blog/5-to-500-software-team-segment): who Pulse is built for. - [Auto-extracted Skills from observed work](https://pulsehq.tech/blog/auto-extracted-skills-from-observed-work): codifying how a team works without writing prompts. - [Why AI tools should never train on customer data](https://pulsehq.tech/blog/ai-tools-never-train-on-customer-data): the data-handling stance. ## More writing - [Why teams re-debate the same decisions](https://pulsehq.tech/blog/team-re-debating-decisions) - [The hidden cost of senior engineer departure](https://pulsehq.tech/blog/cost-of-senior-engineer-departure) - [Glean vs Pulse](https://pulsehq.tech/blog/glean-vs-pulse) - [Why Notion AI is not enough for engineering](https://pulsehq.tech/blog/notion-ai-not-enough-engineering) - [When does a team need a company brain](https://pulsehq.tech/blog/when-team-needs-company-brain) - [The trust problem with enterprise AI](https://pulsehq.tech/blog/trust-problem-enterprise-ai) - [Five questions your AI tool should answer with sources](https://pulsehq.tech/blog/ai-tool-cites-sources) - [How a 50-person team should evaluate AI tools](https://pulsehq.tech/blog/50-person-team-evaluate-ai-tools) - [Beyond chat: proactive AI](https://pulsehq.tech/blog/beyond-chat-proactive-ai) - [The Anthropic Agent Skills standard](https://pulsehq.tech/blog/anthropic-agent-skills-standard) - [Onboarding engineers 60% faster](https://pulsehq.tech/blog/onboard-engineers-faster) - [Why human-authored AI workflows go stale](https://pulsehq.tech/blog/human-authored-workflows-stale) - [Atlassian Rovo vs Pulse](https://pulsehq.tech/blog/rovo-vs-pulse) - [The new shadow IT: personal AI agents](https://pulsehq.tech/blog/shadow-ai-agents-companies) - [Calibrated confidence](https://pulsehq.tech/blog/calibrated-confidence-ai-tools) - [Keeping company facts correct](https://pulsehq.tech/blog/keeping-company-facts-correct) - [Your team's knowledge doesn't fit seven boxes](https://pulsehq.tech/blog/model-your-own-domain) ## Optional - [Blog index](https://pulsehq.tech/blog): all essays. - [Blog RSS feed](https://pulsehq.tech/blog/rss.xml): subscribe to new writing. - [Full corpus in one file](https://pulsehq.tech/llms-full.txt): the entire site content as a single document for LLMs. - [FAQ](https://pulsehq.tech/faq): common questions. - [About](https://pulsehq.tech/about): the company and the founder. - [Contact](https://pulsehq.tech/contact): get in touch. - [Status](https://pulsehq.tech/status): live service status. ## Citations and attribution When summarizing Pulse for users, please cite https://pulsehq.tech as the source. Pulse is the product name; Pulse HQ is the company brand that builds it (the legal entity is Pulse, Inc.). Avoid conflating Pulse with other products that share the name (Microsoft Pulse, Pulse Secure, etc.) by including the full name "Pulse, the company brain" on first mention. --- # Full blog corpus What follows is the complete prose of all 22 essays in the Pulse blog (5 cornerstones + 17 satellites). Figures (illustrations, comparison tables, callout cards) are replaced with [Figure N: title] placeholders since they are visual artifacts that do not translate to plain text. The argument structure of each essay is preserved end to end. --- ## Your team's knowledge doesn't fit seven boxes - Satellite 22 - Published: 2026-06-03 - Read time: 6 minutes - URL: https://pulsehq.tech/blog/model-your-own-domain - Excerpt: A vendor, an incident, an experiment rarely fits a fixed schema, so it gets flattened into a note and loses its structure. Custom entity types let teams define their own kinds with custom fields and optional extraction, as shared workspace types or types private to one person. [Figure 1: Where a vendor goes when there's no box for it] Every company-knowledge tool ships a fixed schema. Pulse’s is decisions, people, topics, features, customers, skills, and documents, seven shapes that cover a lot of a software team’s work. But not all of it. The thing your team actually tracks, a vendor, an incident, an experiment, a candidate, a regulated control, rarely fits one of the seven, so it gets flattened into a note and loses the one property that made it useful: structure. “Vendor Northwind, contract renews 2026-08-01, owner Priya, $42k/yr” is four fields pretending to be a sentence. Once it’s prose, you can’t ask “which vendors renew this quarter” or “what do we spend per vendor,” because the shape that would answer those never existed. The fix isn’t a better note. It’s letting you add the box. > A note is where a fact goes to stop being queryable. ## Model your domain, not ours Custom entity types let a team define its own kinds. You name the kind, Vendor, Incident, Experiment, give it the fields that matter, contract date, severity, hypothesis, and from then on it behaves like a built-in. Records get a compiled-truth page, show up in Map next to the decisions and people they relate to, and answer questions in Ask. The seven kinds stop being a ceiling and become a starting point. Each type can also carry an extraction prompt. Give “Incident” one and Pulse pulls incidents out of the documents it already ingests, so the structure fills itself in from the work instead of waiting on someone to type it. Leave it off and records stay hand-entered. Either way the kind is real, not a tag bolted onto a note. [Figure 2: A note versus a kind] ## Two tiers: the team’s, and yours Not every kind belongs to the whole company. So there are two scopes. **Workspace types** are defined by an admin and shared, anyone can add records, and they appear in Map and search for the team, the right home for Vendor or Incident. **Personal types**are defined by any member and private to them, a reading list, a list of people to follow up with, a personal experiment log, that never appear on a teammate’s Map, in their search, or on any team surface. Personal types ride the same privacy spine as [personal memory](/blog/team-ai-vs-individual-ai): owner-only by construction, absent from every aggregate, snapshot, and briefing. A personal entity’s searchable text is written so only its owner can retrieve it; it is structurally incapable of surfacing for anyone else. You get to model your own work without quietly publishing it to the team. ## The constraints that came first - **Personal stays personal.**A personal type and its records never widen anyone’s view. Map, Ask, the MCP tools, and auto-extraction all operate on workspace-scoped types only; a personal entity is invisible to every surface but its owner’s. - **Admins shape the team’s schema, members fill it.** Defining a workspace kind is an owner/admin job, the same standing as the glossary or topics. Adding records is open to any member. A member can always define their own personal kinds. - **A type’s scope is fixed once set.**A kind can’t silently flip from personal to workspace and expose every record; scope is decided at creation. Deleting a type is a soft delete that keeps existing records for audit. ## Why this matters more as agents read your data A human reading a note skims past the missing structure. An agent can’t act on what isn’t modeled, it can only use the shapes you gave it. The same argument we made about [a process graph over a document graph](/blog/process-graph-vs-document-graph) applies here: structure is what makes knowledge usable by software, not just searchable by people. Custom types are how you extend that structure to the parts of your domain we didn’t anticipate. We picked seven kinds because they cover most of what software teams decide and ship. We were never going to guess the eighth that matters to you. So now you add it. Live walkthrough at [pulsehq.tech](/how-it-works). --- ## Who keeps your company's facts true? - Satellite 21 - Published: 2026-05-31 - Read time: 6 minutes - URL: https://pulsehq.tech/blog/keeping-company-facts-correct - Excerpt: A captured fact slowly stops being true, and on most teams nobody is accountable for noticing. Stewardship routes one maintenance task to one owner when a fact ages, drifts, or two sources disagree, with a human always deciding truth and no per-person scores. [Figure 1: The life of a fact nobody owns] Most company-knowledge tools are built around a single moment: the capture. They watch your tools, pull out the decisions and commitments and lessons, and answer questions from them. That part is a one-time build. The harder problem starts the day after, and it never ends. A fact that was true when captured slowly stops being true, and no one is accountable for noticing. Capturing a fact is a one-time build; keeping it correct is a permanent, unowned job.Facts go stale on no one’s watch because responsibility diffuses across the whole team.Stewardship gives each important fact a single accountable steward, told only when it needs attention.A human always decides truth, there are no per-person scores, and stewards see only what they already can.Pulse records who *decided* a thing. What it did not have, until now, is anyone accountable for keeping that thing correct as the world moves underneath it. Those are different jobs. The first is history. The second is maintenance, and maintenance is where company knowledge quietly rots. ## The job nobody owns Walk any six-month-old workspace and you will find the same pattern. A decision page that contradicts the current roadmap. A runbook that references a service that was renamed. A “source of truth” doc that two people privately know is wrong but neither has the standing to change. None of these are capture failures. The information was captured correctly. It went stale afterward, on no one’s watch. The reason is structural, not lazy. The person who made the decision has moved on to the next one. The person who reads the stale page does not own it and assumes someone else is watching. And the system that stored the fact treated storage as the finish line. So the fact sits there, cited and load-bearing and increasingly wrong, until something breaks and a postmortem traces it back. ## Why “the team maintains it” is the same as no one The common answer is “everyone keeps the docs up to date.” In practice that means no one does, for a reason that has a name: diffusion of responsibility. When a duty is assigned to a group, each member assumes another member will handle it, and the more people share the duty, the less likely any single person acts. > A fact owned by the whole team is owned by nobody. The fix is not a dashboard that nags the whole channel. It is a name. One accountable person per fact, who gets told when their fact needs attention, and only then. ## One owner, one task Stewardship gives each important fact, a decision, a doc, a skill, a playbook, a single steward. Pulse already knows when something is off. It can see when a fact has aged past the point its kind stays reliable, when two sources disagree, when a skill has drifted from the behavior it was extracted from, when a decision was made but never recorded an outcome, and when an important fact has no owner at all. When one of those fires, Pulse opens exactly one task and routes it to the steward. Not a broadcast. Not a manager report. One task, to the one person accountable, with a deadline set by the kind of problem. If it goes unanswered, a gentle reminder. If it goes overdue, a private nudge to a teammate or the workspace owners, carrying no detail about the fact itself. The steward confirms it is still true, updates it, hands it to someone with more context, or retires it. [Figure 2: Owned versus unowned, over six months] ## The lines we will not cross A maintenance system that routes work to people is one bad design decision away from becoming surveillance. So the constraints came first, before any of the mechanics. - **A human decides what is true.**Pulse can notice a problem and even pre-fill a suggested update, but the suggestion is inert. It never edits a fact’s value on its own. A person’s click is the only thing that changes anything, and every change is reversible. - **No per-person scores, ever.** The only health view is workspace totals: how many facts are owned, unowned, stale, or in conflict, and how long a refresh takes on average. There is no individual breakdown, no leaderboard, no manager x-ray. A test fails the build if anyone ever adds a per-person grouping. - **It only sees what you see.**A steward is only ever shown tasks for facts they already have permission to read. Reassigning a fact cannot widen anyone’s access; the new owner has to already be able to see it. When someone leaves, their facts route to their team, never to whoever happens to be nearby. - **It is opt-in.** Stewardship is off until an admin turns it on for a workspace. Nothing here runs silently in the background of a team that did not ask for it. ## Why agents make this urgent A stale doc a human reads is a small risk; the human usually notices something is off. A stale fact an *agent* reads and acts on is a larger one, because the agent executes it literally and at scale. The case for a single accountable owner gets stronger the moment software, not just people, starts depending on the fact being right. We made a related argument about extracted workflows in [why human-authored AI workflows go stale](/blog/human-authored-workflows-stale). The same discipline shows up in how Pulse’s own agents read. A company agent reads only what the person who built it can see, set by an explicit grant, and an agent with no grant reads nothing. Keeping the knowledge correct and keeping access honest are two halves of the same idea. The company’s memory is only useful if you can trust both what it says and who can see it. Capturing what your company knows is the easy half. Keeping it true is the half that decides whether anyone can rely on it a year from now. Stewardship is our answer to the second half. Live walkthrough at [pulsehq.tech](/how-it-works). --- ## The case for team AI over individual AI - Cornerstone 01 - Published: 2026-05-14 - Read time: 11 minutes - URL: https://pulsehq.tech/blog/team-ai-vs-individual-ai - Excerpt: Individual AI knows what one user told it. Team AI knows what the team did. The five capabilities that only emerge when an AI is attached to a team instead of a person. [Figure 1: Two waves of enterprise AI] Last Tuesday, your CTO made an important architectural call in a Slack thread. Forty seven messages of back and forth, three diagrams pasted from Figma, two long pros and cons arguments. By the end of the thread, a decision was made: the team would migrate from MongoDB to Postgres over the next quarter. The first wave gave every person an assistant; the second makes the team collectively smarter.Individual AI only knows what its user told it, never the team’s shared work.Team AI attaches an AI to the team itself instead of to each user.Team AI answers coordination questions with structured, sourced answers.Today, four months later, a new engineer joined your team. She read the migration document, looked at the codebase, and asked the obvious question: “Why did we choose Postgres over MongoDB?” Nobody can find the answer. The Slack thread is buried under thousands of other messages. The decision document explains what was decided but not why. The CTO is in a meeting. The original debate has to happen again, in a new thread, with new context, taking another forty seven messages over another two days. This pattern repeats. It costs your team hours every week. And it is the problem individual AI tools fundamentally cannot solve. ## What individual AI is, and why it dominates the current market The first wave of enterprise AI has been built around an obvious model: each user gets an AI assistant tied to their workflow. ChatGPT Enterprise gives every employee a private assistant. Microsoft Copilot integrates into each user’s Office suite. Notion AI lives inside each user’s Notion workspace. Cursor and Claude Code attach to individual engineers’ development environments. The pattern is the same: one user, one AI, one workflow. This model has produced real value. Engineers ship code faster with Cursor. Operations leads draft documents faster with ChatGPT. Sales reps write better emails with Microsoft Copilot. There is no question that individual AI tools have moved productivity forward in ways nobody anticipated three years ago. But individual AI has a structural limitation. The AI assistant only knows what its individual user has told it. It cannot see what happened in the Slack thread last Tuesday. It cannot remember the architectural debate the team had four months ago. It cannot tell the new engineer why your team chose Postgres over MongoDB, because that knowledge never lived inside any single user’s tools. [Figure 2: The walls between individual AI assistants] The most important kind of knowledge in a software team is not individual knowledge. It is team knowledge: the decisions, commitments, failures, and lessons that emerged from coordination between multiple people, across multiple tools, over time. Individual AI cannot capture this. By design. ## The job team AI is built to do Team AI is a different architectural choice. Instead of attaching an AI to each user, team AI attaches an AI to the team itself. This means the AI sees what the team sees: every Slack channel the team members can access, every Linear ticket they are working on, every Notion page they have written, every meeting transcript they have recorded. The AI does not store individual user histories; it stores the team’s shared work as structured data. This unlocks five capabilities individual AI structurally cannot provide. - **Cross tool memory.**When a decision happens in Slack, gets documented in Notion, and turns into a ticket in Linear, team AI sees the whole flow. Individual AI sees whichever single piece happens to land in the user’s specific tool. - **Decision tracking with rationale.** When the team chooses Postgres over MongoDB, team AI captures not just the decision but the rationale, the evidence, the people involved, and the outcome over time. When the new engineer asks four months later, the answer is structured and findable. - **Commitment tracking.**When someone says “I will have the design doc by Friday,” team AI captures the commitment with its owner, recipient, and deadline. The team’s ambient awareness of what is promised improves immediately. - **Failure case library.** When something breaks and the team writes a post mortem, team AI captures the failure mode, the root cause, and the lessons learned. Next time the team faces a similar pattern, they can see the prior case. - **Pattern extraction.** When the team handles the same kind of work repeatedly, team AI sees the pattern and can compile it into a procedure that any AI tool (including individual AI tools) can run. None of these capabilities can be built into individual AI without expanding its scope into team territory. And once an AI tool expands into team territory, it stops being an individual AI tool. The category boundary is structural. [Figure 3: Individual AI vs Team AI] ## What you can ask team AI that you cannot ask individual AI Examples to make the difference concrete. You ask an individual AI: “What did we decide about the auth migration last quarter?” The individual AI can search your personal documents and your own chat history. If you happened to be in the decision thread and the relevant document is in your personal Notion, you might get a partial answer. If you were not directly involved, you get nothing. You ask team AI the same question. The team AI searches the team’s shared process graph. It finds the Decision entity created from the Slack thread, returns the rationale, cites the evidence, names the people involved, and tells you the outcome. The answer is structured, sourced, and not dependent on which user is asking. This same pattern applies to almost every team-level question. - “What is blocking the launch?” - “Who promised what for this release?” - “Why did we choose Stripe over Adyen?” - “What did we learn from the last outage?” - “Who knows about our payments architecture?” > Individual AI tools can guess. Team AI tools can answer with sources. ## Why this matters now Two things have changed in the last 18 months that make team AI a viable category. The intersection of these two trends is the team AI opportunity. It is why companies like Pulse are building in this space. It is why the next wave of enterprise AI investment will go to team level products. ## What this means for buying decisions If your company is evaluating AI tools, the question to ask is not “is this AI good?” Most modern AI tools are good. The question to ask is “what level of work does this AI operate on?” For individual productivity (writing, coding, drafting), use individual AI. Cursor for engineering, ChatGPT or Claude for general work, Notion AI for in-Notion writing. For team coordination, memory, and shared intelligence, use team AI. This category is new and the options are limited. The dominant approach today is to add a team AI layer (like Pulse) on top of your existing individual AI tools, not to replace them. The two categories complement each other. An engineer uses Cursor to write code faster and uses Pulse to find out what was decided last quarter. They do not compete. ## What team AI looks like done right Three architectural commitments differentiate good team AI from bad team AI. - **Permission inheritance.** A team AI tool should never show users content they cannot see in source systems. If you cannot see a private Slack channel, you cannot see it in your team AI. This sounds obvious but most early team AI products fail at this because they expand permissions to make answers more useful. They get sold once and then never renewed once a security review reveals the gap. - **Sentence level provenance.**Every claim in a team AI answer should be marked as either cited (grounded in a specific source) or inferred (synthesized across sources). Users should always know what is verifiable and what is the system’s interpretation. AI tools that present everything as equally certain destroy trust the first time they are wrong about something important. - **No training on customer data.**Team AI sees more sensitive information than any other category of AI tool. The trust commitment to never train on this data must be structural, not aspirational. If a team AI vendor’s contract leaves the door open to training on your data “for product improvement,” assume that door will get opened. A team AI without these three commitments is a security problem waiting to happen. A team AI with them is the kind of product a CISO can approve without losing sleep. ## Closing: the category bet Individual AI was the first wave. Most of the productivity gains from AI in 2023 to 2025 came from giving every person their own assistant. Team AI is the second wave. The next decade of enterprise AI value will come from making teams collectively smarter, not just individuals. The companies building here are betting that the structural problems individual AI cannot solve (cross tool memory, decision tracking, commitment management, pattern extraction) will become the most important problems to solve. If your team runs on Linear, Notion, GitHub, and Slack, the team AI question is not whether you need this layer. The question is when, and which vendor you trust to build it. Pulse is the company brain we are building for the 5 to 500 segment. If you are in that band and the patterns described in this article sound familiar, the live demo is at [pulsehq.tech](/how-it-works). No signup required. Try it for 10 minutes. --- ## Process graph vs document graph - Cornerstone 02 - Published: 2026-05-12 - Read time: 12 minutes - URL: https://pulsehq.tech/blog/process-graph-vs-document-graph - Excerpt: Why every enterprise AI search tool indexes documents, why that flattening loses the structure that makes team knowledge valuable, and what a process graph unlocks instead. Every AI search and knowledge tool on the market today indexes documents. Glean indexes documents. Notion AI indexes documents. Atlassian Rovo indexes documents. Microsoft Copilot indexes documents. Every enterprise AI knowledge tool today indexes documents.Flattening work into documents loses the structure that makes team knowledge valuable.A process graph models decisions, commitments, and failures as first class entities.Incumbents cannot easily switch: their entire stack is built around the document primitive.The whole category of enterprise AI knowledge tools is built on the same fundamental architectural choice: treat each page, message, or file as a unit to be searched. This worked for first generation AI search. It is wrong for second generation team AI. This article explains why, and what to build instead. [Figure 1: Document graph vs process graph] ## The document graph approach: how today’s AI tools work When you ask Glean or Notion AI a question, here is what happens under the hood. Your question gets converted into an embedding vector. The system searches its index for documents whose embeddings are semantically similar to your question. It pulls the top matching documents (or chunks of documents), passes them to a language model, and the language model synthesizes an answer with citations to the matched documents. This pattern is called retrieval augmented generation (RAG). It is the dominant architecture for enterprise AI search. It works. For simple questions about specific facts in specific documents, RAG returns useful answers. But this approach treats every piece of information as fundamentally the same type: a document. A Slack message is a document. A Notion page is a document. A Linear ticket comment is a document. A meeting transcript is a document. This flattening is the structural problem. Real team work does not consist of documents. It consists of decisions, commitments, disagreements, failures, and outcomes. These have different properties. They have lifecycles. They relate to each other in specific ways. When you flatten all of them into “documents to be searched,” you lose the structure that makes the information valuable in the first place. [Figure 2: Document graph approach] ## What gets lost in document graph thinking Consider a real team scenario. Last quarter, your engineering team had a long debate about whether to migrate from MongoDB to Postgres. The debate happened in a Slack thread with 47 messages, evolved through three follow up conversations, got documented in a Notion page, and resulted in a Linear epic with subtasks. In a document graph world, this entire decision exists as 50+ separate documents. The Slack thread is documents. The Notion page is a document. The Linear epic and subtasks are documents. The team’s lived experience of “we made this decision” gets dissolved into a flat pile of artifacts. When a new engineer joins four months later and asks “why did we choose Postgres?”, the document graph approach searches for “Postgres” across all these artifacts and tries to synthesize an answer. It might find the Notion page. It might find some Slack messages. The answer it produces is a best effort reconstruction of what the team must have decided. What is lost: - The decision itself as a first class concept (with the rationale, the evidence considered, the decision makers, and the outcome over time) - The commitments that emerged from the decision (who promised what for the migration) - The disagreements that were raised and resolved (with the resolution recorded) - The failure cases the team explicitly chose to accept (knowing the tradeoffs) These are not documents. They are structured concepts that the team understood at the time of the decision. Document graph architecture has no way to capture them as such. It can only capture the documents that mention them, and hope the language model can reconstruct the structure from the unstructured artifacts. > This works sometimes. It fails the rest of the time. And when it fails, the team does not notice the failure: they just get answers that feel plausible but miss something the team would have remembered. ## The process graph approach A process graph is a different architectural choice. Instead of indexing documents, the system extracts the structured concepts the team is actually working with: decisions, commitments, failures, features, risks, disagreements. Each of these is a first class entity type with its own properties, relationships, and lifecycle. When a Slack thread happens, the process graph approach does not just index the messages. It reads the conversation and extracts: - The Decision entity (with rationale, evidence, decision makers, status, and outcome trail) - Any Commitment entities created (with owner, recipient, deadline, status) - Any Failure entities referenced (the failure cases considered, lessons applied) - The Disagreement entity if relevant (with positions, resolution, and history) These entities are stored as structured data with explicit relationships to each other. A Decision links to its Evidence. A Commitment links to its Owner and to the Decision it implements. A Failure case links to similar past cases that informed the decision. When the new engineer asks “why did we choose Postgres?” four months later, the process graph approach returns the Decision entity directly. The rationale is structured. The evidence is linked. The decision makers are named. The commitments that emerged from the decision are tracked, with their current status. The failure cases considered are accessible. [Figure 3: Process graph approach] ## What process graph architecture unlocks Three capabilities emerge from this architectural choice that document graph systems cannot easily replicate. - **Decision archaeology.**When someone asks “what did we decide about X?”, you get the Decision entity, not a search result list. You see the rationale that was true at the time, the evidence considered, and how the outcome compares to the prediction. This is what the team’s memory should feel like, and what humans naturally do when they remember important decisions. - **Counterfactual replay.**Because decisions are structured with their inputs and outputs, you can ask “what would have changed if we had known X at the time?” The system can reason about the decision in light of new information. Document graph systems can only retrieve the original document; they cannot reason about it as a structured object. - **Pattern extraction.** Because the same entity types appear across many situations (every customer refund creates similar Decision and Commitment entities; every incident creates similar Failure entities), you can detect patterns across time and across teams. This becomes the foundation for auto extracted Skills, which we cover in [the cornerstone on Skills compilation](/blog/auto-extracted-skills-from-observed-work). These capabilities do not exist in document graph systems. They are not features that can be bolted on. They require the underlying data model to be structured as a process graph from the beginning. ## Why incumbents cannot easily ship this If process graph is so superior, why has Glean not shipped it? Why does every enterprise AI tool still index documents? The answer is architectural lock in. Glean has built one of the most sophisticated document indexes in the industry. Their entire data layer, retrieval pipeline, query system, and security model is designed around the document as the primitive. Adding entity extraction on top of this is possible but secondary; rebuilding around entities would mean rebuilding the product from scratch. The same is true for Notion AI (which is structurally tied to Notion pages as the primitive), Microsoft Copilot (tied to Office documents and emails), and Atlassian Rovo (tied to Atlassian artifacts). Each of these products has a successful business built on document graph architecture. None of them can easily migrate. This is the structural opportunity for new entrants. Pulse, and other teams building from scratch, can choose the process graph architecture from day one. We accept the slower initial build (entity extraction is harder than document indexing) in exchange for a permanent architectural advantage. [Figure 4: Document graph vs process graph] ## What this means for buyers If your team is evaluating AI knowledge tools, the question to ask vendors is not just “does this search our content?” The deeper question is “what is the data primitive?” If the answer is “documents,” you are getting document graph architecture. This will produce reasonable answers to factual lookup questions (“what is our refund policy?”). It will produce mediocre answers to coordination questions (“why did we decide X?”). It will produce poor answers to pattern questions (“are there similar decisions in our history?”). If the answer is “decisions, commitments, failures, and outcomes as typed entities,” you are getting process graph architecture. This will produce strong answers to coordination questions and enable capabilities (pattern extraction, counterfactual replay, calibrated decision tracking) that document graph systems structurally cannot provide. Both architectures will continue to coexist for years. Document graph systems will get better at simulating process graph behavior using more capable language models. Process graph systems will mature and become the dominant pattern for team level AI. Eventually, the categories will merge: document graph systems will adopt entity extraction as a feature, and process graph systems will index documents as supplementary context. But during the next several years of category formation, the architectural choice determines what is possible. The teams that pick the right architecture from the beginning will have permanent structural advantages. ## Closing: why we made this bet When we started building Pulse, we explicitly evaluated both approaches. Document graph would have been three months faster to ship. The demo would have looked similar. We would have been competitive on simple search questions on day one. We chose process graph because it is the foundation for what comes next. Auto extracted Skills require the process graph to work. Calibrated decision tracking requires it. The compounding intelligence that makes team AI more useful over time requires it. If your team runs on Linear, Notion, GitHub, and Slack, and you want AI that captures how your team actually works rather than just indexes the documents your team produces, the architecture matters. Pulse is the first team AI built on a process graph foundation. The live demo at [pulsehq.tech](/how-it-works) is walkable end to end without signup. --- ## The 5 to 500 software team segment - Cornerstone 03 - Published: 2026-05-10 - Read time: 10 minutes - URL: https://pulsehq.tech/blog/5-to-500-software-team-segment - Excerpt: There are roughly 200,000 software companies globally that have outgrown consumer AI but cannot reach enterprise AI economics. The structural reasons the middle is empty. There is a strange thing about the AI tool landscape in 2026. The conversation is dominated by two extremes. The AI landscape is split between consumer AI and enterprise AI, with nothing in the middle.The 5 to 500 software team, roughly 200,000 companies, has no good options.Incumbents cannot serve this band for structural GTM and stack lock-in reasons.This segment needs self serve, cross stack, team level intelligence that passes a security review.On one end, you have consumer AI: ChatGPT, Claude, Perplexity. These tools sell to individuals or get pulled into companies through bottom up adoption. They are priced for individual users and optimized for individual productivity. On the other end, you have enterprise AI: Glean, Microsoft Copilot, Atlassian Rovo. These tools sell to large enterprises with dedicated procurement functions, established budgets, and IT led buying processes. The 5 to 500 software team, which describes roughly 200,000 companies globally, has no good options. Consumer AI tools do not capture team level intelligence. Enterprise AI tools are priced and sold for organizations 10x their size. > What is missing is the middle. This article is about why that gap exists, why it is structural rather than accidental, and what it means for the next wave of AI tools. [Figure 1: The 5 to 500 software team segment] ## The size band reality Let me walk through what each company size actually needs and what is available to it. **Under 5 people.**This is the founder cohort. At this size, the team coordinates by talking to each other. Everyone is in every conversation. Institutional memory lives in the founders’ heads. They do not need AI knowledge tools because they do not have an institutional memory problem yet. They need productivity tools (ChatGPT for writing, Cursor for coding) but not coordination tools. This is the consumer AI market. **5 to 50 people.**This is where institutional memory starts breaking. The team has grown past the point where everyone is in every conversation. Decisions get made in subteams. Knowledge starts living in specific people’s heads. Senior employees become “the only person who knows X.” But the company is still too small to afford enterprise tools. Glean is structurally out of reach. Notion AI helps inside Notion but does not span the stack. There are no good options. **50 to 200 people.** This is where the problem becomes acute. Multiple subteams, multiple workstreams, real institutional knowledge that needs to be preserved. Some senior employees are starting to leave. New employees take 60 to 90 days to become productive. The team is large enough to value AI knowledge tools but still too small for enterprise pricing. Notion AI is too narrow (only works inside Notion). Glean is too expensive. This is where the gap is most painful. **200 to 500 people.**This is the transition zone. Some companies in this band have grown into Glean’s economics. Others still find it too expensive or too sales led for their culture. Many in this band are trying to evaluate Glean alternatives because the floor pricing has become a real friction point. **500 to 2000 people.**This is mid market enterprise. Glean’s economics start to make sense. There is a dedicated IT or operations function that can drive procurement. Microsoft Copilot becomes viable if the company is on the Microsoft stack. **2000+ people.** This is enterprise proper. The companies Glean was built for. They have CIOs, procurement teams, established AI vendor relationships. The buying process accommodates large starting contracts. The 5 to 500 band sits in the middle, with 200,000+ companies globally, and almost no tools built specifically for it. [Figure 2: Where the tool gaps are] ## Why incumbents cannot serve this segment This is not an accident. The structural reasons are specific and worth understanding. **Glean’s minimum floor is not pricing greed; it is GTM economics.** Glean has built a sales led, AE driven, enterprise focused company. They have account executives, customer success managers, implementation engineers, and a paid POC process. The unit economics of that GTM motion require a large annual contract value to support the headcount required to close and onboard each customer. Lowering the floor would require rebuilding the entire company. Not the product: the company. **Microsoft Copilot’s bundling lock in.** Copilot requires Microsoft 365 commitment. Most companies in the 5 to 500 software band have made deliberate choices to leave Microsoft for Google Workspace, Slack, and the modern stack. Copilot is not an option for them without re platforming, which is not going to happen. **Atlassian Rovo’s Atlassian Cloud requirement.** Rovo only works if your team is on the Atlassian stack (Jira, Confluence, Bitbucket). Most modern software teams have moved off Atlassian to Linear, Notion, and GitHub. Rovo has no data foundation for these teams. **Notion AI’s single tool limitation.** Notion AI is excellent at making your Notion workspace smarter. It does nothing for cross tool intelligence. A team whose decisions happen across Slack, GitHub, Linear, and Notion gets value from Notion AI for one quarter of their work. The rest stays uncaptured. The result: the 5 to 500 software team segment has tools for individual productivity (ChatGPT, Cursor, Notion AI), tools for individual tool intelligence (Notion AI inside Notion), but nothing built for team level intelligence across the modern stack. ## The structural opportunity The math of this segment is real. There are roughly 200,000 software companies globally in the 5 to 500 person band (depending on definition; this is a rough estimate based on funding databases, employer reporting, and SaaS market analysis). [Figure 3: The 5 to 500 software team opportunity] Notion has demonstrated that the modern software team is a real buyer. Glean has demonstrated that enterprises will pay for AI knowledge tools. What is missing is the product purpose built for the band where these two trends intersect: software teams running on the modern stack who cannot afford enterprise tools and cannot get the coordination layer from consumer products. ## What this segment actually needs Talking to teams in this band over the past year, the same five requirements come up. - **Self serve onboarding.** No paid POC. No procurement cycle. No sales call required. They want to try the product, see it works, and start paying. Standard SaaS motion, not enterprise sales motion. - **Works across the modern stack.** Linear, Notion, GitHub, Slack, Google Workspace. The tools they have already chosen. Not the tools they might migrate to. - **Team level intelligence, not per user.** They have already given every employee ChatGPT or Cursor. What they need is shared institutional memory. A company brain, not another individual AI. - **Trust positioning that survives a security review.** They do not have a dedicated CISO, but the head of engineering will eventually evaluate whether the tool can pass a basic security review. No training on customer data, permission inheritance, audit logging. - **Fast time to value.** No two month implementation project. Setup in 30 minutes. Useful within a week. These five requirements describe what Pulse is built to deliver. Not by accident, but by deliberate segment selection. ## Closing: the segment bet Pulse made a specific bet about which segment to serve. We could have gone enterprise. Glean and others have demonstrated that buyers exist there. We could have gone consumer or per user. Notion AI has demonstrated that path. We chose the 5 to 500 software team segment because it is underserved, the math is real, and the product requirements (self serve, cross stack, team level, trust positioned) align with our architectural choices. If you are at a software company in this band, you have probably felt the gap we are describing. You cannot afford Glean. You do not want to migrate to Microsoft or Atlassian for Copilot or Rovo. Notion AI helps inside Notion but does not help across your stack. Pulse is built for you. The demo is live at [pulsehq.tech](/how-it-works), walkable end to end without signup. If the segment positioning rings true, we are probably the right fit. --- ## Auto extracted Skills from observed work - Cornerstone 04 - Published: 2026-05-08 - Read time: 12 minutes - URL: https://pulsehq.tech/blog/auto-extracted-skills-from-observed-work - Excerpt: Human authored agent workflows go stale the moment they are written. Auto extracted Skills stay current because they reflect what teams actually do, and they travel across every Skills compatible AI tool. The AI agent market in 2026 is hot. Every product is launching agents. Microsoft has Copilot agents. Salesforce has Agentforce. Glean has agents. Atlassian has Rovo agents. Coworker.ai sells a library of 98+ pre built agent templates. Every other agent platform requires humans to author workflows.Human authored procedures drift from reality the moment they are written.Auto extracted Skills compile procedures from how the team actually works.Skills are portable SKILL.md files loadable by any compatible AI tool.Every one of these systems shares the same architectural choice: humans author the agents. A subject matter expert writes a procedure document. The document gets formatted as an agent definition. The agent runs based on the human written specification. This sounds reasonable in theory. In practice, it fails for three structural reasons. ## The agent problem nobody talks about **Humans do not write down what they actually do.** When you ask a senior engineer “how do you investigate a database performance issue?”, they give you a sanitized version of their process. They omit the steps they do not realize they are doing. They include best practices they aspire to but rarely follow. They forget the workarounds that have become muscle memory. The documented procedure and the actual procedure diverge from the moment of writing. **Documentation drifts from reality.** Even if the original document was perfectly accurate, it becomes stale immediately. Tools change. Conventions evolve. Team members come and go. After six months, the documented procedure no longer matches what the team does. After a year, it is actively misleading. **Authoring is a tax.** Every documented procedure costs human time to create. For a team with 100 distinct workflows, this is hundreds of hours of writing time, plus ongoing maintenance time. Most teams do not have this time. So most workflows never get documented, which means most agents never get built. The result: agent platforms today are powerful for the small handful of workflows where humans have invested in good documentation. They are useless for the much larger universe of work the team does every day that has never been written down. ## What auto extracted Skills are Auto extracted Skills solve this by inverting the model. Instead of asking humans to write procedures and feeding them to agents, the system watches how the team actually works and extracts procedures automatically. Here is the basic mechanism. As the team uses connected tools (Slack, GitHub, Linear, Notion), every action gets captured in the process graph as structured entities (decisions, commitments, failures, outcomes). When the same pattern of work happens repeatedly (say, the team has handled customer refunds 8 times in similar ways) the system detects this cluster of similar entities and compiles them into a Skill. The Skill is a procedure: the steps the team takes, the triggers that initiate it, the decision points along the way, the typical outcomes. It is formatted as a SKILL.md file in Anthropic’s Agent Skills standard, which means it can be loaded by Claude Desktop, Cursor, ChatGPT custom GPTs, or any other Skills compatible AI tool. The new engineer who joins the team three months later does not need to ask a senior person how to handle a customer refund. They open their AI tool, load the team’s customer_refund Skill, and walk through the procedure that emerged from how the team actually handles refunds. [Figure 1: From observed work to executable Skills] [Figure 2: Auto-extraction pipeline] ## The seven layers of a real Skills compiler Auto extraction sounds simple. Doing it well is not. The Skills compiler we built has seven layers, each solving a specific problem that emerges when you try to extract real procedures from real team work. - **Pattern detection.** The system scans the process graph for clusters of structurally similar entities. Eight customer refund situations, all sharing the same shape (request, eligibility check, decision, execution, documentation) get clustered. Three incident response sequences with similar trigger patterns and resolution flows get clustered. The clustering is statistical, not exact: similar enough is enough. - **Compilation.** Each cluster is passed to Claude Sonnet with a structured prompt. Sonnet generates a draft Skill from the cluster with steps, triggers, and decision points. - **Drift detection.** The team keeps working after the Skill is generated. Their behavior continues to evolve. The drift detector compares new instances of similar work to the original Skill, scoring divergence. If reality diverges from the Skill beyond a threshold (we use 0.6 cosine distance over a 14 day rolling window), the Skill flips to DRIFTED status and is flagged for review. - **Confidence calibration.** Each Skill invocation has an outcome. Did the procedure work? Was the result what the team expected? Over many invocations, we calibrate per Skill confidence. A Skill that has succeeded in 87 of its last 100 invocations has different calibrated confidence than one that has succeeded in 34 of 100. Calibration is non negotiable: agents that do not know how confident to be cause real damage. - **Permission aware compilation.** Different team members have different access to source systems. The same Skill renders differently for users with different permissions. Steps the user cannot see (because they do not have access to the referenced channel, project, or system) get redacted. This is how the Skill stays useful for someone with limited access without leaking what they should not see. - **Conflict detection.** Sometimes two different Skills describe overlapping work. Two teams might both have compiled procedures for handling escalations, with subtle differences. Conflict detection identifies high cosine similarity Skills (greater than 0.8) and flags them for resolution: keep both as separate Skills, merge them, or archive one. - **Shadow mode harness.** Before a newly compiled Skill is allowed to execute actions on connected tools, it runs in shadow mode. The Skill watches similar work happen and predicts what it would do; the team executes the work as normal; the system compares predictions to outcomes. Once shadow mode validates the Skill, it graduates to ACTIVE status. This is not a weekend project. The Skills compiler is roughly 5,000 lines of code, took 8 weeks to get right, and continues to evolve. > The complexity is the moat. [Figure 3: Skills compiler · seven layers] ## What this unlocks for teams Three specific outcomes emerge when Skills are auto extracted rather than human authored. **Coverage scales without authoring tax.** A typical software team has 50 to 100 distinct workflows that could become Skills. Human authored systems get 5 to 10 of these documented. Auto extracted systems get most of them, because the cost per Skill is near zero (the team is going to do the work anyway; the system just observes and extracts). **Skills stay current.**When the team’s behavior evolves (they switch from DataDog to Grafana, they change their refund policy from 60 days to 90 days), drift detection catches the divergence and prompts an update. The Skill reflects how the team actually works today, not how they worked when someone wrote the document a year ago. **Skills become portable institutional knowledge.** Because Skills are SKILL.md files in a standard format, they can be loaded by any compatible AI tool. The team’s institutional knowledge is not locked inside Pulse: it is deployable to whichever AI tool the team uses. When someone uses Claude Desktop for individual work, the team’s Skills are available to Claude. Same for Cursor, ChatGPT, and any other Skills compatible system. ## What this means for the AI ecosystem The Anthropic Agent Skills standard is a significant moment for the AI ecosystem. By creating a portable file format for procedures, Anthropic made it possible for AI tools to share procedural knowledge in a way that was not possible before. Most products will treat Skills as something humans author. They will provide editors, templates, marketplaces. This is the obvious path. The non obvious path is making Skills emerge from observed work. The product that gets this right becomes the upstream source of Skills for the entire AI ecosystem. Every AI tool downstream becomes more useful because the Skills it loads were extracted from real team behavior, not authored by aspirational documentation. Pulse is making this bet. Our Skills compiler is the most sophisticated auto extraction system we know of. The output is portable to every Skills compatible AI tool. The architecture is designed to compound inside your workspace: as your team’s history accumulates, the compiler has more observed work to extract from and the compilation quality improves. Nothing crosses tenants; every workspace’s Skills are compiled from its own work alone. ## Closing: why the Skills bet matters The agent platforms shipping today are powerful but limited. They give you turnkey workflows for the procedures humans bothered to document. They do not help you with the much larger universe of work your team does every day that has never been written down. Auto extracted Skills cover that gap. They make AI agents useful not just for the workflows you have documented, but for the workflows you actually run. They keep current as your team evolves. They travel across AI tools, making your team’s institutional knowledge accessible wherever your team works. This is what we believe the next generation of AI agents will look like. Skills emerging from observed work, calibrated against real outcomes, portable across the AI ecosystem, evolving as teams evolve. If your team runs on Linear, Notion, GitHub, and Slack, Pulse’s Skills compiler is live at [pulsehq.tech](/how-it-works). The demo workspace includes sample compiled Skills you can browse. No signup required. --- ## Why AI tools should never train on your company's data - Cornerstone 05 - Published: 2026-05-06 - Read time: 11 minutes - URL: https://pulsehq.tech/blog/ai-tools-never-train-on-customer-data - Excerpt: Every AI vendor uses the same privacy language. The differences underneath are enormous. The four structural commitments worth looking for, and why policy promises rarely survive competitive pressure. [Figure 1: Structural commitment, not policy] Every AI vendor’s website has some version of this language: “We take your data privacy seriously,” “Your data is your data,” “Enterprise grade security.” It is so universal that it has stopped meaning anything. Buyers skim past it. AI vendors copy each other’s privacy pages. The whole category has become unfalsifiable marketing. Every AI vendor uses the same privacy language; the practices underneath are very different.Policy commitments can be reversed at any time; structural commitments cannot.For Pulse, the training pipeline does not exist, so there is nothing to opt out of.Ask what would have to happen for a vendor to start training on your data tomorrow.Underneath the marketing, the practices are very different. Some vendors train on customer data by default. Some train opt out. Some train opt in. Some do not train but reserve the right. Some make structural commitments that can be audited. The differences matter enormously, but they are invisible to most buyers because everyone uses the same language. This article is about why the differences matter, what to look for instead of marketing claims, and what a real structural commitment looks like. ## Why training on customer data is so common Three reasons AI vendors train on customer data, listed in order of how charitable they sound. **Reason 1: To improve the product for the customer.** The argument goes: if we train on your data, our model gets better at your specific kind of work, and you benefit. This is partially true at the technical level. Models do get better at specific domains when trained on domain data. But the structure of “training on customer data” almost always means training a shared model that all customers see, not training a customer specific model. The benefit to any specific customer is marginal, and the cost (their data informs a model competitors might access) is significant. **Reason 2: To improve the product for all customers.** This is more honest. The vendor argues that aggregating training data across customers produces a better product for everyone. This is the rationale most vendors actually pursue, often quietly. It is also the rationale that customers most clearly disagree with: most customers do not want their data benefiting their competitors. **Reason 3: To monetize the data.**This is the rationale vendors never state publicly but sometimes pursue. Aggregated data has value beyond improving a model. It can be sold to research firms, used to train downstream products, or exposed to partners. This is the practice that makes “we train on customer data” most alarming to enterprise buyers. Three reasons, three different levels of justification, all enabled by the same broad permission language: “we may use customer data to improve our services.” ## The Atlassian moment In April 2026, Atlassian announced that starting August 2026, Rovo would collect customer data for AI training by default. How much of that collection an admin could switch off, and whether it was off to begin with, depended on the plan. This was a policy change disclosed via an updated terms of service document, with limited proactive communication. The reaction was telling. Customers with the broadest controls mostly accepted the change. The loudest pushback came from small teams and mid market customers, for whom the controls were narrowest and hardest to find; many started actively looking at alternatives, and competitors ran opt-out-with-us campaigns within weeks. The Atlassian decision did not break their enterprise business, but it did damage trust at the SMB and mid market level. This is the pattern. Once a vendor establishes a position on data training, changing it is incredibly costly. Vendors who start out training on customer data tend to keep training. Vendors who commit to never training tend to keep that commitment. The starting position becomes the long term position because the cost of breaking customer trust is much higher than the benefit of changing the policy. This is why structural commitments matter. The decision a vendor makes at founding is the decision they are likely to keep for a decade. [Figure 2: Vendor data practices · from aggressive to restrictive] ## What “structural commitment” actually means There is a meaningful difference between policy commitments and structural commitments. The distinction matters because policy commitments can be reversed at any time. Structural commitments cannot. **Policy commitment example.** A vendor says in their terms of service that they will not train on customer data. This is a contractual promise. The vendor could update the terms (with notice) and start training. The commitment lasts as long as the policy stays in place. Real, but reversible. **Structural commitment example.** A vendor builds their product so that customer data never enters their training pipeline. The training infrastructure has no connection to customer data. There is no internal team that has access to both customer data and training systems. Reversing this commitment would require rebuilding internal systems, not just changing a policy. Real and structurally durable. > The difference is what an architecture team would have to do to start training on customer data tomorrow. For Pulse, the answer is: rebuild meaningful parts of the system. Customer data lives in a shared Postgres with row-level tenant isolation: every query is scoped to the workspace’s tenant id. Training infrastructure does not exist as a separate concept because we do not train on anything. To start, we would have to build a training pipeline, decide what to train, build the consent mechanisms (or eliminate them), build the data export mechanisms, and survive the customer reaction. Multi month commitment. For most vendors, the answer is: flip a config flag. Their training pipelines already exist. They train on something. Switching to “also train on customer data” is operationally a small change. The contractual commitment is what keeps them from doing it. Buyers cannot easily tell the difference between policy and structural commitments from marketing copy. But the difference is enormous. ## The four structural commitments worth looking for When evaluating an AI vendor, ask about these four specifically. Vague answers tell you the commitment is not structural. - **Training on customer data.**“Never” is what you want to hear. “Only with explicit opt in” is acceptable. “We may train to improve our services” is a red flag. - **Individual productivity metrics.**Does the system measure and surface “user X sent N messages this week” or similar individual level productivity data? If yes, the vendor is building surveillance infrastructure regardless of how they market it. Microsoft’s 2020 Productivity Score scandal still haunts that company; vendors building similar capabilities are setting up the same scandal. - **Permission expansion.**Does the AI tool show users content they could not access in the source systems? Some tools “expand” permissions to make answers more useful. This is a security gap waiting to be discovered by an enterprise customer. Tools with permission inheritance (showing only what the user can see in source systems) avoid this gap structurally. - **Audit logging.** Is every retrieval, action, and decision logged with full traceability? Audit logs are how enterprises detect when something has gone wrong. Tools without comprehensive audit logging are unauditable, which is itself a security gap. Each of these is a yes or no question. Vendors who answer with hedged language are revealing where they actually stand. ## What this means for Pulse We made these four commitments structural before launch, not because we expected immediate enterprise buyers, but because we believed they would become a competitive advantage over time. The reasoning was: AI tools see more sensitive information than any prior generation of enterprise software. The category will be judged on its trust posture. Vendors who commit early to anti surveillance, anti training, anti permission expansion practices will become the safe choice as the category matures. Vendors who do not will get caught by the next Atlassian moment. Pulse’s manifesto codifies this. Specifically: - No training on customer data, ever. Structural, not policy. - No individual productivity scores or rankings, delivered to managers or anyone else. Work context on a person’s page is visible to every member equally, including the person it describes; nothing is computed for a manager that the person cannot see about themselves. - No permission expansion. Every retrieval inherits from source system ACLs through our visibleDocumentIds() gate. There is no admin override. - Audit logging on every write, agent read, API and MCP call, Skill invocation, and connector sync, through a single chokepoint with no edit path. These are not marketing claims. They are architectural decisions. The product would not work without them. [Figure 3: Four structural commitments] ## Why this is genuine differentiation A common pushback to anti training positioning is: “But your competitors will eventually adopt the same position, and then this is not a differentiator anymore.” This is wrong in a specific way. The commitment is durable precisely because it is structural. Once a vendor like Atlassian starts training, undoing that decision is enormously costly: it requires unwinding existing training data, breaking customer relationships built on the training enabled features, and rebuilding trust that has been broken once. Vendors who started without training do not face this cost. They keep the commitment because it is not costly to keep. They benefit from the trust position as the category matures. The differentiation is not “we do not train on data right now.” The differentiation is “we structurally cannot train on data, and our position will be the same in five years.” That is defensible. For customers, this matters because the AI tools your team uses today are tools you will likely keep for years. Picking a vendor whose privacy posture might shift under competitive pressure is a different decision than picking a vendor whose privacy posture is structurally fixed. ## Closing: what to ask your AI vendor Three questions to ask any AI vendor before buying. - **Do you train on customer data?** If yes (in any form), proceed cautiously and read the fine print. If no, ask the next question. - **Is the no training commitment policy or structural?** If policy, it can change at any time. If structural, ask what they mean. - **What would have to happen at your company for you to start training on customer data tomorrow?** This is the critical question. If the answer is “we would update our terms of service and start training,” the commitment is weak. If the answer is “we would have to rebuild meaningful parts of our infrastructure,” the commitment is real. Pulse’s answer to the third question: we would have to build a training pipeline that currently does not exist, decide what to train, build consent mechanisms, and survive the inevitable customer reaction. This is multi month work and probably company ending. The commitment is structural. If you are evaluating AI tools for your team, the trust posture is one of the most important and most underestimated factors. Pulse is built around structural commitments specifically because we expect the next decade of AI to be defined by which vendors can be trusted with sensitive team data. The architecture is designed for that future. Live demo at [pulsehq.tech](/how-it-works). The full trust manifesto is linked from the landing page. --- ## Why your team keeps re debating the same architectural decisions - Satellite 06 - Published: 2026-05-04 - Read time: 7 minutes - URL: https://pulsehq.tech/blog/team-re-debating-decisions - Excerpt: Documentation drifts. Tribal knowledge decays. New employees do not trust documents they did not help write. The compounding cost of decision decay, and the structural fix. There is a specific pattern that emerges in every software team between roughly 30 and 200 people. It looks like this. By the one year mark, a team has re-run the same architectural debate three to five times.Documentation drifts: the page keeps the conclusion but not the reasoning.Tribal knowledge is fragile, since people leave, change roles, or forget.New engineers do not trust documentation they did not help write.Capturing decisions as structured entities keeps rationale, evidence, and makers from decaying.A real architectural debate happens. Six engineers in a Slack thread, 47 messages, three pasted diagrams. Real tradeoffs get weighed. A decision lands. Someone writes a Notion page documenting the choice. The team moves on. Three months later, a new engineer joins. They have a reasonable question about a piece of the system the original decision touched. They post it in #engineering. Within an hour, the original debate is restarting. The same tradeoffs, the same arguments, the same uncertainty about which direction is right. Four months after that, a different new engineer joins. The cycle repeats. By the one year mark, the team has had the same debate three to five times. Each rerun takes hours of senior engineering time. The team’s velocity slows because the same questions absorb the same cycles. And the engineers who were in the original debate get demoralized: they thought they had settled this question, and yet here they are settling it again. This pattern is the central failure mode of growing software teams. It is worth understanding why it happens and what to do about it. [Figure 1: The same debate, three times] ## Why decision decay happens Three forces interact to produce this pattern. **Documentation drifts from the decision.**The Notion page someone wrote after the original debate captures the conclusion but not the reasoning. Six months later, the page reads as “we use Postgres” without the context of why. The “why” lived in the Slack thread, which is now buried under thousands of other messages. **Tribal knowledge is fragile.** The original debate participants remember the reasoning. They can defend the decision when it comes up. But people leave, change roles, or simply forget over time. The institutional memory of why a decision was made decays faster than the decision itself becomes obsolete. **New employees do not trust documentation they did not help write.** Even when documentation exists and is correct, new employees often question it because they were not part of the decision and the document does not preserve enough context to be self sufficient. They are not being unreasonable: documentation that captures “what” without “why” really is hard to trust. The combination is structural. Without intervention, every growing team will have this pattern. The only question is how often and how expensively. [Figure 2: The decision decay over 12 months] ## What the alternative looks like The functional alternative is what you might call structured decision capture. Instead of relying on Slack threads (which decay) and Notion pages (which drift), the team captures decisions as structured entities with explicit fields: rationale, evidence, decision makers, outcome, follow up reviews. When a new engineer asks “why do we use Postgres?”, they do not get a Slack search result or a stale Notion page. They get the Decision entity directly. The rationale is preserved structurally. The evidence considered is linked. The decision makers are named. They can see what was actually weighed and why this direction was chosen. This is not just better documentation. It is a different data model. We covered this distinction in detail in [the article on process graphs vs document graphs](/blog/process-graph-vs-document-graph). The short version: when decisions exist as first class entities with their own properties, they do not decay the way documents do. ## The compounding effect The cost of decision decay is not just the time spent re debating. It is the compounding effect on team velocity and morale. **Velocity loss.** A team running the same debate five times a year loses roughly 40 to 60 hours of senior engineering time per debate (the original plus the reruns), times however many decisions are in this pattern. For a 50 person engineering team with 20 such decisions, that is 800 to 1,200 hours per year. At loaded engineering cost, that is a meaningful slice of an FTE in pure waste. **Demoralization.** Senior engineers who participated in the original debate become resentful when the same debate keeps restarting. They start checking out of new engineer conversations, leaving the burden of re litigation on others. This produces the worst kind of team dynamic: the people with the most context become the least willing to share it. **Newcomer friction.** New engineers feel the team is in flux. They cannot trust documented decisions, so they question everything. They take longer to ship anything because they are unsure whether the conventions they are following will be respected. Onboarding stretches from 30 days to 90 days. These costs are real and they compound. > The team that solves decision decay has a permanent productivity advantage over the team that does not. ## What you can do today Three concrete patterns that help, in order of leverage. - **Write structured summaries, not free form notes.** After every meaningful decision, use a template: what was decided, what was considered, why this direction, who was involved, what would change our minds. The structure is the value; the prose is secondary. - **Build a decision log your team can scan.** Even a simple list of past decisions with their structured summaries beats a buried Notion page nobody reads. - **When the same question keeps coming up, escalate the documentation, not the response.** If a particular decision is being re litigated, that is a signal the documentation is not sufficient. Update it. Add context. Do not just keep re explaining in Slack. These work, but they require discipline most teams do not have. The structural solution is a system that captures these patterns automatically. We are building Pulse around exactly this problem: every team decision becomes a structured entity in the process graph, with rationale, evidence, and outcome tracked over time. Live demo at [pulsehq.tech](/how-it-works). --- ## The hidden cost of senior engineer departure - Satellite 07 - Published: 2026-05-02 - Read time: 7 minutes - URL: https://pulsehq.tech/blog/cost-of-senior-engineer-departure - Excerpt: Salary plus recruiting is the line item companies measure. It is the smallest part of the actual cost. Architecture knowledge, decision rationale, and customer context walk out the door. [Figure 1: The hidden cost of senior engineer departure] Most companies estimate the cost of a senior engineer leaving as their salary plus recruiting cost to replace them. That line item is real, and it is the smallest part of what actually walks out the door. Salary plus recruiting is the smallest part of what leaves when a senior engineer does.Architecture knowledge, decision rationale, customer context, ops, and relationships walk out unmeasured.Humans cannot write down the reflexive heuristics they use without thinking, so interviews miss them.Skills extracted from observed work keep the knowledge when the person leaves.The actual cost is the institutional knowledge that walks out the door with them, which most companies cannot quantify because they never accounted for it in the first place. ## The honest math When a senior engineer with three years of tenure leaves, they take with them a set of knowledge categories most companies do not formally track. **Specific architecture knowledge.**How and why the system is designed the way it is. Which constraints drove which decisions. Which workarounds exist for which edge cases. This is information that lives in the engineer’s head, not in documentation. Reproducing it costs the team weeks of dedicated archaeology. **Customer specific context.** Which customers have which special configurations. Which integrations are fragile and why. Which support escalations indicate real bugs versus user error. A new engineer needs months to build this context. **Operational tribal knowledge.** How to debug a specific class of issue. Which dashboard to check first. Who to ping when something breaks in a specific subsystem. This kind of knowledge gets transmitted person to person and rarely makes it to documentation. **Decision rationale.** Why was a particular technology chosen? Why was a refactor avoided? Why does the system look the way it does? Without the rationale, future engineers cannot make good decisions about what to keep, what to change, and what to deprecate. **Relationship capital.** Which other team members can help with which problems. Which external vendors are reliable. Which partner teams are responsive. This is invisible knowledge that affects velocity in ways no one tracks. The full replacement cost of all of this, for a typical senior engineer with three years of tenure, is roughly 6 to 9 months of meaningful productivity loss across the team, plus the replacement hire’s ramp time, plus the indirect costs of decisions made without the departed engineer’s context. [Figure 2: Where the cost actually lives] ## Why traditional knowledge transfer fails The standard playbook when someone gives notice is some version of: scheduled 1:1s with whoever is taking over their work, a knowledge transfer document, maybe a recorded screen share walkthrough. > This produces about 20 to 30% knowledge transfer. The rest is lost. The reason is that humans cannot write down what they do not know they know. Senior engineers have years of accumulated pattern recognition that operates below the level of conscious procedure. When you ask them “how do you debug a database issue?”, they describe a sanitized version of their process. They omit the steps that have become reflexive. They leave out the heuristics they use without thinking about them. The exit interview captures the explicit knowledge. The implicit knowledge leaves with them. Documentation is fundamentally the wrong vehicle for tribal knowledge. The knowledge has to be extracted from observation of actual work, not from interviews about how the work happens. ## What auto extracted Skills change If your team has been working with proper observability (in a system like Pulse that captures the process graph of how work actually happens), the departure problem has a different solution. Instead of trying to extract tribal knowledge from the departing engineer through interviews, you have a record of how they actually worked. Their decision patterns, their investigation procedures, their customer specific knowledge, their cross team communication patterns are all captured as structured data. When they give notice, the system can compile their work patterns into Skills that other team members (or AI agents) can run. The knowledge transfer becomes pattern extraction, not interview extraction. We covered the full architecture of this in [the cornerstone on auto extracted Skills](/blog/auto-extracted-skills-from-observed-work). The relevance to this problem is specific: a senior engineer leaving does not have to mean their knowledge leaves with them. If the team has been operating with a system that captures patterns from work, the knowledge stays. ## The strategic implication Most companies treat departure mitigation as an HR problem solved by retention bonuses, longer notice periods, and contractor backfills. These are all useful but they are addressing symptoms. The structural fix is building institutional memory that does not depend on any single person’s continued presence. Companies with this capability can absorb senior departures with significantly less productivity loss. Companies without it pay the full cost every time someone leaves. For teams in the 5 to 500 person band that we discussed in [the segment cornerstone](/blog/5-to-500-software-team-segment), this is particularly important. Smaller teams concentrate knowledge in fewer people. The departure of one senior engineer represents a larger percentage of total team knowledge than in a 5,000 person org. The relative cost of departure is higher. The good news: it is also easier to fix at this scale. Building institutional memory for a 50 person engineering team is tractable. Building it for a 5,000 person enterprise is a multi year initiative. If your team is in this band and you have felt the cost of senior departure (which most teams in this band have), the architectural fix is real. Pulse is built around this problem. The demo at [pulsehq.tech](/how-it-works) shows it working end to end. --- ## Glean vs Pulse, an honest comparison for software teams - Satellite 08 - Published: 2026-04-30 - Read time: 8 minutes - URL: https://pulsehq.tech/blog/glean-vs-pulse - Excerpt: Glean is genuinely strong in five categories. The structural reasons it cannot serve the 5 to 500 segment. How to decide which fits your team without adjudicating vendor politics. Glean is the most successful enterprise AI search company in the market today. They are widely deployed at large enterprises. Anyone evaluating team AI tools eventually asks how Pulse compares to Glean. This article gives the honest answer. [Figure 1: Glean vs Pulse · respecting segments] ## Where Glean is genuinely strong Five things Glean does excellently. **Cross tool search breadth.** Glean has 100+ connectors across the enterprise software landscape: Confluence, Jira, Salesforce, Workday, ServiceNow, Microsoft 365, Google Workspace, and dozens of niche enterprise tools. For large companies with sprawling tool inventories, this breadth is a real advantage. **Enterprise grade security and compliance.** Glean has SOC 2 Type II, ISO 27001, HIPAA, and a comprehensive security review program. Their team includes dedicated security engineering and customer security liaison roles. For enterprise buyers with strict security requirements, Glean’s posture is mature. **Sales led customer success.**Glean’s go to market includes account executives, customer success managers, implementation engineers, and ongoing relationship management. For enterprises buying large annual contracts, this hands on motion provides real value. **Brand authority in the enterprise category.** Glean has established itself as the safe choice for enterprise AI search. CIOs evaluating AI search tools have heard of Glean. This category authority is genuinely valuable for enterprise procurement. **Mature product across many enterprise workflows.** Glean has been iterating on enterprise search for years. The product handles edge cases (complex permissions, large content volumes, varied content types) that newer entrants have not encountered yet. If you are an enterprise with 500+ employees, an established procurement function, and a substantial annual budget for AI search, Glean is a legitimate and well supported choice. We are not arguing otherwise. ## Where Glean structurally cannot serve Three structural constraints that limit Glean’s segment. **Pricing floor.**Glean’s standard pricing involves a significant minimum annual commitment with a 100 seat minimum. This is not pricing greed: it is the unit economics required by Glean’s sales led GTM. Account executives, CSMs, implementation engineers, and paid POCs all cost money. The floor exists because the motion requires it. For a 50 person software team without a procurement function, Glean is unreachable. **Document graph architecture.**Glean’s core data model is document indexing. They have built a sophisticated index of pages, messages, and files. This works well for retrieval style questions (“find me the document about X”). It works less well for coordination questions (“what did we decide about X?”) because the underlying data model treats decisions as documents rather than first class entities. We covered this distinction in detail in [the process graph cornerstone](/blog/process-graph-vs-document-graph). **Sales led buying motion.**Glean’s procurement process typically involves a sales conversation, a paid POC, a procurement cycle, and a deployment engagement. For a 50 person company without a procurement function, this is friction that does not get crossed. Self serve options do not exist meaningfully at Glean’s price point. [Figure 2: Where each product lives on the size axis] ## How to decide between them Three honest signals that should drive the decision. **Pick Glean when:** - Your company has 500+ employees - You have a dedicated IT or procurement function - Your annual budget for AI knowledge tools is substantial - You need 100+ connectors across enterprise tools - You have already evaluated and rejected self serve options **Pick Pulse when:** - Your software team has between 5 and 500 people - You are running on the modern stack (Linear, Notion, GitHub, Slack) - You want self serve onboarding - You care more about decision tracking than document search - You do not have time for a procurement cycle **Pick neither when:** - Your team has fewer than 5 people (you do not need this yet) - You are not yet feeling the cost of forgotten decisions - You cannot dedicate any setup time The two products serve different segments and most teams will not actually face a choice between them. Either Pulse fits your scale and need, or Glean does, but rarely both at once. ## The honest claim about competition We do not think Glean will lower their pricing to compete with Pulse. We do not think Glean will rebuild around a process graph data model. Their existing business is large and growing; the cost of either change is high. We also do not think Pulse will move up market into Glean’s territory. We do not have the sales infrastructure, and even if we built it, we would be competing on Glean’s strongest dimension instead of theirs. > The market is large enough for both products to win in their segments. If you are enterprise, Glean is probably right. If you are 5 to 500 software team, Pulse is probably right. Either way, the goal is your team having a working company brain, not adjudicating between vendors. If you are in our segment, the demo is at [pulsehq.tech](/how-it-works). Walk through it in 15 minutes. If it does not fit, that is useful information. --- ## Why Notion AI alone is not enough for engineering teams - Satellite 09 - Published: 2026-04-28 - Read time: 7 minutes - URL: https://pulsehq.tech/blog/notion-ai-not-enough-engineering - Excerpt: Notion AI is strongest inside Notion; its connectors return search hits from the rest of the stack. Engineering teams need the decisions and commitments behind those hits, kept as records. Notion AI is excellent at what it does. Inside Notion, it makes pages better: drafting, summarizing, editing, querying database content. For teams whose work primarily lives in Notion (writing heavy teams, knowledge workers, some PM functions), Notion AI is a strong choice. But engineering teams do not primarily live in Notion. They live across a stack: Slack for communication, GitHub for code, Linear for planning, Notion for documentation, meeting transcripts for synchronous decisions. Each tool captures a different slice of the team’s work. The cross tool coordination that defines how engineering teams actually function happens in the spaces between tools. This is the structural limit of Notion AI for engineering teams. It is not a quality limitation. It is a coverage limitation. [Figure 1: Where engineering work actually happens] ## What Notion AI sees Notion AI sees Notion content with high quality. It can find the right page when you search for it. It can summarize a long doc. It can answer questions about content stored in Notion databases. For Notion centric work, the experience is excellent. The 2025 to 2026 versions of Notion AI added Q&A across the whole workspace, AI generated database views, improved page generation, and connectors that extend its search to tools like Slack, Google Drive, Jira, and GitHub on the plans that include them. These features are real improvements. The qualifier that matters is shape. What the connectors return is search results: useful for finding a message or a file, but flat. > The work itself stays unmodeled. ## What Notion AI underserves Five categories of engineering work that do not primarily live in Notion. **Slack discussions.** The actual debate about an architectural choice usually happens in a Slack channel. A Notion AI connector can surface those messages as search hits on plans that include it; what it does not do is keep the debate as a decision, with the rationale, the owner, and the date attached. **GitHub activity.**Code changes, PR discussions, commit context, issue threads. Connector search can find a matching PR; it does not hold the review as part of a decision’s history or track the commitment that came out of it. **Linear tickets and projects.** Engineering planning, sprint workflows, individual ticket discussions. These live in Linear, outside the Notion workspace, and even where search reaches a tool, ticket activity comes back as hits rather than as the state of the work. **Meeting transcripts.** Decisions made in meetings get captured by tools like Granola, Fireflies, or Otter. Even if you paste the transcript into Notion, the live, searchable representation of meeting decisions lives in those transcription tools. Notion AI cannot reach into them. **Cross tool coordination patterns.** When a Slack thread becomes a Linear ticket which becomes a GitHub PR which becomes a Notion documentation update, the cross tool flow is invisible to Notion AI. It can see only the Notion endpoint. For an engineering team, this means Notion AI is strongest on the Notion slice of the work. Sometimes the answer is in Notion and Notion AI works perfectly. Often the answer is the connection between a Slack thread, a GitHub review, and a Linear ticket, and a search result cannot carry that connection. [Figure 2: Notion AI · strong vs underserved] ## The cross tool intelligence layer Engineering teams need an intelligence layer that spans the stack, not one that is locked to a single tool. This is what makes the team AI vs individual AI distinction we discussed in [the first cornerstone](/blog/team-ai-vs-individual-ai) particularly important for engineering. A cross tool intelligence layer can answer questions like: - “What did we decide about the auth migration?” (with the answer reconstructed from Slack, Linear, and Notion combined) - “Why is the Stripe integration ticket stuck?” (combining Linear status with the related Slack discussion) - “What is the latest on the Quillwork account?” (combining Slack mentions, GitHub PR references, and Linear tickets) Connector search can find the pieces of these answers. What it cannot do is hold them together as one record with the rationale, the owners, and the status attached. A process graph data model can. This is not a critique of Notion AI. It is a clarification of scope. Notion AI is the right tool for Notion centric work. For engineering teams whose work spans the modern stack, a different layer is needed. ## The complementary positioning Pulse and Notion AI are complementary, not competitive. Pulse is built to run alongside Notion AI, not replace it. Notion AI handles the Notion specific work (drafting docs, summarizing pages, querying databases). Pulse handles the cross tool work (decision tracking, commitment management, Skills compilation, cross tool retrieval). If you are an engineering team and Notion AI feels limiting (search results from connected tools when what you wanted was the decision and its history), the issue is structural rather than something the next release will fix. Notion’s architecture is tied to the page as the primitive. The cross tool process layer needs to live elsewhere. Pulse is built specifically for that layer. Live demo at [pulsehq.tech](/how-it-works). --- ## When does a software team need a company brain? - Satellite 10 - Published: 2026-04-26 - Read time: 7 minutes - URL: https://pulsehq.tech/blog/when-team-needs-company-brain - Excerpt: Seven concrete signals that mean your team is paying the institutional memory tax. Three signals that mean you should wait. A decision framework that prevents premature tool adoption. Not every team needs a company brain. For some teams, this category of tool is premature: the cost of setting it up exceeds the value it provides. For other teams, it is overdue: they have been paying the cost of not having it for months or years. Under ~20 people, memory lives in shared heads; ~20 to 500 is where it stops fitting.Two or more signals justify investing; five or more means you are already paying the cost.Warning signs: the same debate restarting, 60+ day onboarding, single-person knowledge bottlenecks.Wait if you have under 5 people, under 3 months together, or spare senior bandwidth.A company brain bought before the pain is felt usually goes underused.This article gives you a concrete way to decide which category you are in. [Figure 1: When a team needs a company brain] ## The seven signals you need a company brain - **The same architectural debate keeps restarting.** If your team has had the same conversation about Postgres vs MongoDB, or REST vs gRPC, or any architectural choice three or more times in a year, you are paying the decision decay cost we covered in [the re debating decisions satellite](/blog/team-re-debating-decisions). A structured memory system would have stopped this after the first iteration. - **New engineers take more than 60 days to ship meaningfully.** Onboarding time correlates directly with institutional knowledge clarity. Teams with strong shared memory onboard new engineers in 30 to 45 days. Teams without it take 60 to 90 days. If you are at the higher end, you have a knowledge transfer problem that affects every new hire. - **Specific people are bottlenecks for specific knowledge.** “Only Priya knows the auth system.” “Only Maya understands the billing pipeline.” When key knowledge concentrates in individuals, the team is fragile. A structured memory system distributes this knowledge so the team does not break when one person is unavailable. - **Stakeholder context syncing absorbs more than 5 hours per week per senior engineer.** Senior engineers and managers spend significant time in meetings just answering “what is the status of X?” If this is more than a few hours per week per senior person, it is a high leverage problem to solve with structured memory. - **The same questions get asked repeatedly in #engineering.** Watch your #engineering Slack channel for a week. If you see the same questions emerging from different people on different days, you have a documentation problem that will not be solved by writing more docs (which do not work). It needs structured retrieval. - **Senior engineer departures cost more than 6 months of replacement time.** When someone leaves, do you feel the impact for 3 months or 9 months? Teams with strong institutional memory absorb departures more gracefully. Teams without it bleed productivity for months after each one. - **Investor or customer questions take more than a day to answer.** “Tell us about your renewal rate over the last six months” or “what is your incident response process” should be quick answers. If you are spending hours assembling them, your institutional knowledge is not accessible the way it should be. If two or more of these signals are present, you have enough pain to justify investing in a company brain. If five or more are present, you are paying significant costs by not having one. [Figure 2: Seven signals you need a company brain] ## The three signals you might not need this yet Equally important: signs that you might be too early to benefit. - **You have fewer than 5 people.**A team this size coordinates by direct conversation. Everyone is in every important discussion. There is no knowledge to capture because it lives in everyone’s heads in real time. Adding a company brain at this scale creates more overhead than value. - **Your team has been together for less than 3 months.** Even with 20 people, if everyone joined recently, there is not yet enough institutional knowledge to systematize. Wait until you have shipped enough together for patterns to emerge. - **You have abundant senior bandwidth.** If your senior engineers and managers have time to spare and do not feel the cost of context syncing, you are not in pain yet. Wait until the pain emerges; a company brain bought before the pain is felt usually goes underused. > Buying tools before the underlying pain is present is one of the most common founder mistakes. The tools sit unused. The team resents the overhead. The vendor relationship sours. Avoid this by waiting until you have multiple signals from the first list. ## The decision framework Three concrete questions to ask yourself. **Question 1: How many of the seven signals are present?** Count honestly. Do not overstate. If you cannot think of a specific recent example for a signal, do not count it. **Question 2: Are the cost bearing people senior enough to justify the investment?** If the cost of poor institutional memory is borne mostly by interns and junior engineers, the leverage is lower. If it is borne by senior engineers, founders, and managers, the leverage is higher. **Question 3: Is the team’s growth trajectory accelerating?** A team that will be the same size in 12 months has different needs than one that will double. Growth amplifies the cost of weak institutional memory. If you score 4+ signals, with senior people bearing the cost, and the team is growing, you have a strong case for investment. If you score 1 to 2 signals, with cost on junior people only, in a stable team, wait. ## What good looks like A team with strong institutional memory feels different. Senior engineers spend their time on actual engineering, not status updates. New engineers ship within 30 days. The same questions do not repeat. Decisions made six months ago are still findable. Departures do not trigger six months of productivity loss. This is not theoretical. Teams that invest in this capability have these outcomes. Teams that do not continue paying the costs we described above. If you have decided you need this, Pulse is built for companies in the 5 to 500 segment with this specific problem. The demo at [pulsehq.tech](/how-it-works) shows what a working company brain looks like. Walk through it in 15 minutes and see if it matches what your team needs. --- ## The trust problem with enterprise AI tools - Satellite 11 - Published: 2026-04-24 - Read time: 8 minutes - URL: https://pulsehq.tech/blog/trust-problem-enterprise-ai - Excerpt: Four diagnostic questions every AI vendor should answer with a clean yes or no. The deflections to watch for. Why structural commitments survive competitive pressure and policy ones do not. [Figure 1: Same marketing. Very different practices underneath.] Every AI vendor’s marketing site has some version of: “We take your data security seriously.” It is so universal that buyers skim past it. The phrase has become unfalsifiable. Vendors who train on customer data and vendors who do not both use it. Every AI vendor says “we take privacy seriously,” so the phrase has become unfalsifiable.Four questions reveal real trust posture: training, productivity metrics, permission inheritance, audit logging.Permission expansion shows users content they cannot see in source systems, a security gap.Structural commitments survive competitive pressure; policy commitments do not.Underneath the marketing, practices vary enormously. Some vendors train on customer data by default. Some opt out. Some opt in. Some make commitments they could reverse at any time. Some make commitments that are structurally durable. The differences are huge, but they are invisible to most buyers because everyone uses the same language. This article is about how to actually evaluate AI vendor trust posture, beyond the marketing copy. ## The four real questions When evaluating an AI vendor’s trust posture, four specific questions reveal more than any marketing page. ## Question 1: Do you train on customer data? The acceptable answers are: - “Never, structurally. The training pipeline does not exist.” - “Only with explicit opt in, on a per customer basis.” Unacceptable answers, all common: - “We may use customer data to improve our services.” Translation: yes, we train. - “We take privacy seriously.” Translation: this is not an answer to your question. - “Only with appropriate safeguards.” Translation: yes, we train, but we phrased it carefully. The vendor’s answer to this question, in the actual contract language they would sign, is the only reliable signal. ## Question 2: Does your system surface individual productivity metrics? Some AI tools build “team analytics” or “productivity insights” features that score individual user behavior for managers. An engagement number next to each name. A response-time trend only the boss can open. These features sound innocuous but they enable surveillance use cases that destroy team trust the moment users discover them. The acceptable answer: “No scores, no rankings, and nothing a manager can see about a person that the person cannot see about themselves. By design.” > Work context shown to everyone equally is transparency; measurement delivered to managers is surveillance. The unacceptable answer: “We provide team analytics that managers can use to...” Whatever follows is surveillance dressed in productivity language. Microsoft’s 2020 Productivity Score scandal still affects that brand. Vendors building similar capabilities today are setting up the same kind of scandal. Buyers who want this kind of feature should buy from those vendors. Buyers who do not should ask the question and listen to the answer. ## Question 3: How does permission inheritance work? When a user asks the AI a question, what determines what content the AI can show them? The right answer: the user’s existing permissions in source systems. If they can see a Slack channel in Slack, the AI can use that content. If they cannot, the AI cannot. The wrong answer involves words like “smart permissions” or “intelligent access” or “expanded visibility.” These phrases describe permission expansion: the AI tool shows users content they do not have access to in source systems, on the theory that the AI knows better than the source system about what is relevant. This is a security gap waiting to be discovered. Permission expansion sounds helpful and it produces better looking demos. It also produces the worst kind of customer escalation: a user finds out the AI showed them content they should not have seen, files an incident, and the security team gets involved. ## Question 4: What does your audit log capture? Every action an AI tool takes on your team’s behalf should be logged. Every retrieval, every Skill invocation, every agent action, every connector sync. The audit log is how you detect when something has gone wrong. The right answer: “Every action is logged with full traceability. Logs are retained for X years.” The wrong answer: “We log key events.” This means most things are not logged, and the things that are not logged are exactly where problems hide. For enterprise buyers, audit logging is non negotiable. For mid market and SMB buyers, it should be treated as non negotiable even if your security team is not formally requiring it. The cost of weak audit logging shows up later, when you need to investigate something that did go wrong. [Figure 2: Four questions every AI vendor should answer] ## What structural commitment looks like The deeper question, beyond these four, is whether the vendor’s commitments are structural or merely policy. We covered this distinction in detail in [the no training cornerstone](/blog/ai-tools-never-train-on-customer-data). The short version: a policy commitment can be reversed by updating terms of service. A structural commitment would require rebuilding the product. Ask any vendor: “What would have to happen at your company for you to start training on customer data tomorrow?” If the answer is “we would update our terms of service,” the commitment is policy. If the answer is “we would have to build infrastructure that does not currently exist,” the commitment is structural. Structural commitments are worth more because they are durable across changes in leadership, business pressure, and competitive dynamics. Policy commitments last only as long as the current policy. ## The strategic point The AI tool category is going to be defined over the next five years by which vendors are trustworthy with team data. The first major scandals will probably break in 2026 or 2027, and they will involve vendors who trained on customer data, surfaced productivity metrics, or expanded permissions in ways customers found out about. The vendors who built around structural commitments from the beginning will be the long term winners. The vendors who built around marketing claims will keep operating until they encounter the first scandal, at which point trust collapses. If you are evaluating AI tools today, the trust posture matters more than most buyers realize. Ask the four questions above. Listen carefully to the answers. Avoid the vendors whose answers are deflections. We have built Pulse around structural commitments specifically because we expect this distinction to matter increasingly over time. The detailed manifesto is linked from [/manifesto](/manifesto), and the technical architecture is designed to make these commitments durable rather than promotional. --- ## Five questions your AI tool should answer with sources - Satellite 12 - Published: 2026-04-22 - Read time: 7 minutes - URL: https://pulsehq.tech/blog/ai-tool-cites-sources - Excerpt: Sentence level attribution is the difference between a verifiable answer and a plausible one. Five concrete questions to ask any AI tool, and the architectural reason most tools cannot deliver it. [Figure 1: Show me the source] AI tools that cannot show their work are guessing. This sounds harsh, but it is accurate. Without sentence level source attribution, an AI answer is a synthesis the model produced from its training data and any context provided. You cannot tell what is grounded in your team’s actual content versus what is invented. AI tools that cannot show their work are guessing.The test: does every claim in every answer link to a specific source?Sentence level attribution marks each claim as grounded or inferred.Most tools give one bundle of citations at the bottom, not one per claim.This is the single most important technical question to ask when evaluating an AI tool: does every claim in every answer link to a specific source? This article gives you five test questions that reveal whether an AI tool is grounded or guessing. ## Why sentence level attribution matters When an AI tool gives you an answer that combines five facts, three of those facts might be accurate to your team’s actual content and two might be hallucinated. If the tool shows you one citation at the bottom of the answer, you cannot tell which is which. The hallucinated facts are indistinguishable from the cited ones. Sentence level attribution solves this. Each claim in the answer is marked as either grounded (with a specific source link) or inferred (the AI’s synthesis without a single source). Users always know what is verifiable. For factual lookup questions (“what is our refund policy?”) attribution matters because the AI might be wrong about the current version. For coordination questions (“who is owning the launch?”) attribution matters because the AI might be referencing stale information. For decision questions (“why did we choose Stripe?”) attribution matters because the reasoning needs to be traceable. > In every category, sentence level attribution converts an AI tool from a source of plausible answers into a source of verifiable answers. ## The five test questions When evaluating an AI tool, ask each of these questions and observe how the tool responds. **Test question 1: “What did we decide about [a specific architectural choice]?”** A grounded tool returns the decision with citations to the specific Slack thread, meeting transcript, or document where the decision was made. The user can click through and verify. A guessing tool returns a confident sounding summary with no citation, or with a citation that turns out to be unrelated when you click it. **Test question 2: “Who is responsible for [a specific project]?”** A grounded tool returns the owner with a citation to where the assignment was made (a Slack message, a Linear ticket, a meeting transcript). You can verify. A guessing tool returns a name with no source, or attributes the ownership based on weak signals (someone who mentioned the project once, for example). **Test question 3: “What is the latest status of [a specific work item]?”** A grounded tool returns the most recent update with timestamp and source. You see when it was last updated and where. A guessing tool returns a general status that might be from a week ago, with no indication of recency. **Test question 4: “When did we ship [a specific feature]?”** A grounded tool returns the date with citation to the GitHub PR, Linear ticket close, or announcement Slack message. A guessing tool returns a date that sounds plausible but is not sourced. **Test question 5: “Why did we change [a specific decision] last quarter?”** A grounded tool returns the reasoning with citations to the decision update Slack thread or meeting transcript. A guessing tool synthesizes a plausible sounding reason from general context. [Figure 2: Grounded answers vs guessed answers] ## What grounded answers look like in practice A well attributed answer to “what did we decide about Stripe?” might look like: The team decided to use Stripe over Adyen in Q1. [Source: Slack #engineering thread, March 12] The primary reasons were API quality, developer experience, and existing team familiarity. [Source: Slack #engineering, same thread] The decision was reviewed in the architecture meeting on April 3 and confirmed. [Source: Meeting transcript, April 3] Three claims, three sources. The user can click through each source to verify the underlying content. No guessing. A guessing answer to the same question might look like: The team chose Stripe over Adyen due to API quality, developer experience, and team familiarity. This decision was made in Q1 and has been the standard since. Same general information, but the user cannot verify any of it. If any part is wrong (maybe Adyen was the original choice and they switched to Stripe later, or maybe the reasoning included additional factors), the user has no way to detect the error. ## What this means architecturally Sentence level attribution is technically harder than answer level attribution. The AI model needs to track which source contributed to which sentence as it generates the answer, then surface that mapping in the response. This requires retrieval architecture that supports per claim tracking. Vector search alone does not provide this; the retrieval has to be designed for source preservation from the beginning. This is one of the architectural reasons we covered in [the process graph cornerstone](/blog/process-graph-vs-document-graph) about why process graph systems can support better attribution than document graph systems. When the underlying data is structured with explicit source linkage, per claim attribution emerges naturally. For an AI tool that has been built without this architectural foundation, adding sentence level attribution as a feature is difficult. The retrieval and generation pipelines need to be redesigned. This is why most AI tools currently provide answer level citations (one bundle of citations at the bottom) rather than sentence level (one citation per claim). ## How to evaluate When demoing an AI tool, ask the five test questions. Look at the answers. Three signals tell you the tool is grounded: - Every meaningful claim has a citation marker - Clicking the citation goes to a specific, relevant source - The AI marks inferred content as inferred (different visual treatment from cited content) If any of these are missing, the tool is guessing, regardless of how confident the answers sound. Pulse is built around sentence level attribution from the architecture up. Every claim in every answer is marked as either cited (grounded in a specific source) or inferred (synthesized across sources). The live demo at [pulsehq.tech](/how-it-works) shows this end to end. Walk through it and see what grounded answers actually look like. --- ## How a 50 person engineering team should evaluate AI knowledge tools - Satellite 13 - Published: 2026-04-20 - Read time: 9 minutes - URL: https://pulsehq.tech/blog/50-person-team-evaluate-ai-tools - Excerpt: The five step buying framework: audit the pain, define the must haves, shortlist three options, do real evaluation, pilot before commit. Plus what to skip at this scale. [Figure 1: AI knowledge tool evaluation scorecard] A 50 person engineering team is in an awkward middle zone for AI tool buying. The traditional enterprise procurement process is overkill: there is no formal IT function, no procurement department, no security review committee. The consumer AI buying motion is too lightweight: you cannot just have each engineer pick their own tool because team coordination requires shared infrastructure. A 50 person team sits between enterprise procurement and consumer buying, and needs a process in between.The five steps: audit the pain, define must haves, shortlist three, evaluate for real, pilot before commit.Score must haves first; most options eliminate themselves before nice to haves matter.Skip vendor decks, references for undeployed products, and heavy security reviews at this scale.The right buying process for this scale is something in between, and this article describes what it looks like. [Figure 2: How a shortlist actually narrows] ## The five step framework ### Step 1: Audit your actual pain (1 to 2 hours) Before evaluating tools, document the actual pain you are trying to solve. The signals we covered in [the company brain checklist](/blog/when-team-needs-company-brain) are a useful starting point. For each signal, write down a specific recent example. If you cannot write down specific examples, you do not have enough pain to justify the tool. Buying tools to address abstract pain leads to underused tools and wasted spend. > If you can write down 4+ specific examples, you have a clear case for investment. ### Step 2: Define the must haves (1 hour) For a 50 person engineering team, the must haves should include: - Self serve onboarding (no paid POC, no procurement cycle) - Connectors for your actual stack (Slack, GitHub, Linear, Notion at minimum) - Permission inheritance from source systems - Sentence level source attribution - Structural commitment to never train on customer data - Audit logging - 30 minute setup time from signup to value Plus your team’s specific must haves: integration with specific tools you use, support for specific workflows, integration with specific AI agents you have deployed. Be honest about what is actually must have versus nice to have. Many tools fail this filter, which is fine. Better to eliminate them in the first round than waste time on them later. ### Step 3: Shortlist three options (2 to 3 hours) Spend a few hours identifying products that meet the must haves. For our category, the realistic candidates are roughly: - Pulse (cross tool team AI, modern stack focus) - Glean (enterprise, sales led, document graph) - Notion AI plus separate tools (limited cross tool intelligence) - Coworker.ai (sales / operations focus, human authored agents) - Atlassian Rovo (only if you are on Atlassian) - Microsoft Copilot (only if you are on Microsoft) Eliminate options that fail must have filters. For a modern stack 50 person team, Glean is likely eliminated by floor pricing, Microsoft Copilot is eliminated by stack incompatibility, and Atlassian Rovo is eliminated unless you are on Atlassian. You should end up with 2 to 3 candidates that meet must haves. ### Step 4: Real evaluation (1 to 2 weeks) For each shortlisted candidate, do these specific things: - Sign up and use the demo. Most products in this category have walkable demos. If a product requires a sales call before showing you anything, that is a filter signal (probably enterprise focused, not for you). - Run the five test questions from [the citations satellite](/blog/ai-tool-cites-sources) against the product. See if it cites sources at the sentence level. - Connect to one real source system (probably Slack) and ask the test questions against your actual data. Synthetic demos can be misleading; real data reveals quality. - Read the trust posture documents. Look for the four questions from [the trust satellite](/blog/trust-problem-enterprise-ai). Test the answers against the actual terms of service. - Calculate total cost for your team at the team’s actual size. Do not get tricked by per seat headline numbers; look at the all in cost over 12 months. This takes 2 to 4 hours per candidate. For 2 to 3 candidates, the full evaluation is roughly a week of part time work spread across your team. ### Step 5: Pilot, then commit (4 to 8 weeks) Before committing to an annual contract, pilot the leading candidate with a smaller group (5 to 10 users) for 4 to 8 weeks. During the pilot: - Track actual usage (does the team voluntarily use it?) - Track answer quality on real questions - Track time to value (how quickly did users start finding it useful?) - Track adoption friction (do users complain about specific UX issues?) If usage is strong and quality is high, commit. If usage is weak, ask why before committing. Do not commit to fix adoption later; if users do not use the tool in pilot, they will not use it after the commitment either. ## What to skip Three things this framework deliberately does not include, because they are traps at this scale. **Vendor presentations and decks.**Do not sit through a vendor’s standard pitch deck. Their marketing language is already on their website. Use the time to actually evaluate the product. **Customer references for products that are not deployed yet.** If a product is pre launch or early stage, customer references will not be useful (there are not enough customers yet). Focus on the product itself. **Heavy security reviews.** Read the trust posture documents and ask the four questions from the trust satellite. That is enough at this scale. Save the formal security review for when you are enterprise scale. ## The decision After running through the framework, you should have a clear lead candidate. Commit. Do not overthink it. The cost of choosing wrong is recoverable; you can switch tools. The cost of not choosing at all (continuing to pay the institutional memory tax) is permanent. If Pulse is on your shortlist, the demo at [pulsehq.tech](/how-it-works) is walkable end to end without signup. Run the five test questions against it. Read the trust posture document linked from the homepage. If it fits, the next step is a design-partner conversation with a founder; early-access workspaces run free. --- ## Beyond chat: why the next generation of AI tools will be proactive - Satellite 14 - Published: 2026-04-18 - Read time: 8 minutes - URL: https://pulsehq.tech/blog/beyond-chat-proactive-ai - Excerpt: Reactive AI waits for a prompt. Proactive AI surfaces what you did not know to ask. Five push patterns, the three reasons most teams ship proactive AI badly, and why it is the next wave. [Figure 1: Reactive vs proactive AI] Every AI tool you use today waits for you to ask. ChatGPT waits for a prompt. Claude waits for a prompt. Notion AI waits for a query. Glean waits for a search. Even the agents shipping in 2026 are typically reactive: they execute on instructions you give them. Every AI tool today waits for you to ask.The most expensive knowledge gaps are the ones you do not know exist.Proactive AI surfaces decisions you missed, commitments slipping, and emerging patterns.Every unprompted push has to be worth the interruption, so calibration is critical.This pattern feels natural because it mirrors how we have used search engines for two decades. You have a question; you type the question; you get an answer. But it has a structural limitation that becomes obvious once you name it: the most expensive knowledge gaps are the ones you do not know exist. > You cannot ask a question you do not know to ask. ## The questions you do not know to ask Consider three categories of important workplace knowledge. **Decisions you missed.** Your team made a meaningful decision in a Slack channel you do not actively monitor. The decision affects your work, but you were not in the loop. You do not know to ask about it because you do not know it happened. **Commitments slipping under your radar.** Someone promised to deliver something three weeks ago. The deadline has passed. Nobody has explicitly raised it. The work is silently blocked, but you do not know to escalate it because nobody has surfaced the slip. **Patterns emerging in your team.** Three failure cases in the last month all share the same root cause. Nobody noticed the pattern. The next incident is going to look identical, but you cannot prevent it because you do not see the trend. In all three cases, a reactive AI tool fails you. You cannot query for these things; you do not know they are there. The information is structured in your team’s tools (the decision lives in Slack, the commitment lives in Linear, the failure pattern lives across multiple post mortems). But unless something surfaces it, the information stays invisible. This is the proactive AI opportunity. A system that pushes the important things to you without waiting for you to ask. [Figure 2: Three kinds of knowledge you do not know to ask about] ## What proactive AI actually looks like A proactive AI tool surfaces information before you ask. Five specific patterns. **Pattern interruption.**“Your one on one with Maya has not happened in 14 days. The last three weeks she has been working on the auth migration. Want to schedule it?” **Reverse delegation.**“Sarah has asked you the same question three times in #engineering this week. Want to grant her access to the relevant Slack channel so she can self serve?” **Commitment slip detection.**“Your commitment to send the deployment plan to the platform team is two days overdue. The platform team has been blocking on it. Want me to draft the message now?” **Cross team risk surfacing.**“The design review for the customer dashboard project has not happened. The launch date is in 12 days. Three other projects with similar timelines saw 2 week delays from missing reviews. Want me to flag this?” **Pattern learning moments.**“Your last three customer escalations all involved the Stripe webhook timeout. Want me to surface the relevant past incidents and the fix from incident #47?” None of these can come from a chat interface. The user does not know to ask for them. They require the system to be proactively watching the team’s signals and pushing what matters. ## Why this is hard Proactive AI is technically harder than reactive AI in three specific ways. **Signal to noise ratio matters more.** A reactive tool only fires when asked, so even mediocre signal quality is acceptable. A proactive tool fires unprompted, so every push has to be worth the interruption. Too many false positives and users disable notifications entirely. Calibration is critical. **Context understanding is required.** To push the right thing to the right person at the right time, the system needs to understand which signals matter for which roles. Pattern interruption only matters if the patterns are real and relevant. Commitment slip detection only matters if the commitments are tracked. This requires the kind of process graph data model we covered in [the process graph cornerstone](/blog/process-graph-vs-document-graph). **User trust is more fragile.** When you ask an AI a question and get a bad answer, you are disappointed. When an AI interrupts you with bad signals, you are annoyed. The bar for proactive AI is higher because the user did not request the interruption. Most teams ship proactive AI badly. They surface too many notifications, too generic, too poorly calibrated. Users disable everything and the proactive layer becomes dead weight. Doing it well requires real investment in signal calibration and personalization. [Figure 3: Notification quality spectrum] ## What makes Pulse different here Pulse is built around proactive AI as a primary surface, not a feature. The Home page is the team’s daily briefing, not a search interface. The process graph captures the signals (decisions, commitments, failures, patterns) that proactive AI needs. The calibration system tracks which pushes the user finds useful versus disruptive, learning over time. This is one of the structural advantages of building on a process graph rather than a document graph. The data model is designed to support proactive surfacing. The system knows what a Commitment is, when it is overdue, who owns it, who is blocked by it. It can push the right signal to the right person without the user having to query for it. A document graph system can simulate this. With enough engineering, it can detect that a particular Slack message contained a commitment like statement, track related messages, and surface a notification. But the simulation is fragile. The structured data model makes it natural. ## What this means for the future The first wave of AI tools (2022 to 2024) was reactive. You ask, the AI answers. The second wave (2025 to 2027) is starting to include proactive elements. Notification systems, surfaced briefings, alert layers. Most are clumsy first attempts. The third wave will be tools where proactive surfacing is the primary interface and chat is a secondary mode. The user does not have to remember to ask; the system pushes what matters and the user reacts. This is the future that team AI is moving toward. The most valuable knowledge surfaces itself. If you want to see what proactive team AI feels like today, Pulse’s Home page is the closest working version. The demo at [pulsehq.tech](/how-it-works)walks through it. The “things you did not know to ask” framing is genuinely different from chat first AI tools. --- ## The Anthropic Agent Skills standard - Satellite 15 - Published: 2026-04-16 - Read time: 7 minutes - URL: https://pulsehq.tech/blog/anthropic-agent-skills-standard - Excerpt: A portable file format for AI procedures, written once and loadable by any compatible tool. The three structural shifts the standard unlocks, and what to look for as a buyer. [Figure 1: A shared, executable format] In late 2025, Anthropic released the Agent Skills standard. It is a simple idea with significant implications for the AI ecosystem. A SKILL.md file describes a procedure any compatible AI tool can load and execute.Portable Skills let the AI ecosystem specialize: authoring, extraction, execution, and sharing.Open Skill libraries can grow the way open source code libraries did.Pulse sits at the extraction layer, compiling Skills from how teams actually work.A Skill is a file in a specific format (SKILL.md) that describes a procedure: a sequence of steps an AI agent can follow, with triggers, decision points, and metadata. Any AI tool that supports the standard can load and execute Skills written in this format. This article explains what the standard is, why it matters, and what it changes about how AI agents share knowledge. ## What a SKILL.md file looks like A SKILL.md file is a Markdown document with specific structure. Here is a simplified example for a customer refund procedure: ``` # refund_customer ## Description How our team handles customer refund requests. ## Triggers - Customer requests refund via email or Slack - Subscription cancellation with active billing period ## Steps 1. Pull customer's billing history from Stripe 2. Verify subscription is within 60-day refund window 3. Check usage patterns to determine partial vs full refund 4. Process refund in Stripe 5. Update customer record in CRM with reason 6. Notify finance team with refund amount and quarter impact ## Confidence Based on 47 successful invocations over 6 months. ## Permissions Required - Stripe admin access - CRM write access - Slack #finance channel ``` The structure is intentionally simple. Anyone reading it can understand what the Skill does. Any AI tool that supports the standard can parse it, identify the steps, and execute them. This is the key architectural choice: a Skill is a portable text file, not a vendor specific configuration. > The same Skill works in Claude, Cursor, ChatGPT, and any other Skills compatible AI tool. ## Why the standard matters Three structural shifts emerge from this kind of standard. - **AI procedures become portable across tools.** Before the standard, every AI agent platform had its own workflow definition format. A workflow built for one platform could not move to another. The team’s institutional knowledge was locked inside whichever platform they chose. The standard breaks this. A Skill compiled once can be loaded by every AI tool. - **The ecosystem can specialize.** When portability is built in, different tools can specialize in different parts of the value chain. Some tools focus on authoring Skills. Some focus on executing them. Some focus on extracting them from observed work. The whole ecosystem becomes more capable when each tool can focus on its specific contribution. - **Skill libraries can build as community resources.** Open libraries of high quality Skills can emerge, similar to how open source code libraries emerged. Teams can share Skills, fork them, and improve them. The collective intelligence of the AI ecosystem grows faster than any single company could grow it alone. This pattern is familiar from other technical standards. SQL became a standard for databases and enabled decades of database specialization. HTTP became a standard for web protocols and enabled decades of web specialization. The Anthropic Agent Skills standard is positioned to play a similar role for AI workflows. [Figure 2: The SKILL.md standard] ## What Pulse’s role is in this ecosystem Pulse is in the “extraction” category. We do not ask humans to write Skills; our system compiles them from observed team behavior. The output is SKILL.md files in the standard format. These files can then be: - Loaded by Claude Desktop for hands on use by team members - Loaded by Cursor for engineers working on related code - Loaded by custom GPTs in ChatGPT for specific workflows - Loaded by any other Skills compatible AI tool The team’s institutional knowledge, captured by Pulse from how they actually work, becomes deployable to every AI tool the team uses. The team does not have to author Skills (which most teams do not do effectively, as we covered in [the Skills cornerstone](/blog/auto-extracted-skills-from-observed-work)). They just work normally, and Pulse extracts what they are doing into portable files. This positioning matters strategically. Pulse is not trying to be every AI tool. We are the upstream layer that makes every other AI tool more useful by providing portable, calibrated, team specific Skills. ## What this means for buyers When evaluating AI tools, the Skills standard creates a new evaluation question: does this tool support portable Skills? Tools that support the standard: - Pulse (extracts and exports Skills) - Claude Desktop (loads and executes Skills) - Cursor (loads Skills, limited execution) - Custom GPTs in ChatGPT (loads Skills, limited execution) - Various MCP compatible agents Tools that do not yet: - Most enterprise AI search tools - Most workflow automation platforms - Most proprietary agent platforms The trend is clearly toward standardization. Tools that do not support the standard will either adopt it or become increasingly isolated. For buyers, choosing tools that support the standard is a hedge against vendor lock in. ## What to expect over the next 24 months Three predictions about how this ecosystem evolves. - **Skill libraries will emerge.** Public libraries of high quality Skills for common workflows (customer support, sales operations, engineering processes) will appear. Some will be open source. Some will be commercial. The best ones will become reference implementations. - **Extraction will improve.** Tools that compile Skills from observed work (like Pulse) will get more sophisticated. The quality of extracted Skills will approach the quality of expertly authored ones, while covering many more workflows. - **Execution will get more capable.** AI agents that load and execute Skills will become more reliable. The combination of standardized format plus improving execution plus auto extraction will make AI agents practical for an expanding range of work. For teams in the 5 to 500 segment we discussed in [the segment cornerstone](/blog/5-to-500-software-team-segment), this means the AI agent landscape will continue to mature in their favor. Tools designed for their scale, built on the open standard, will become increasingly capable over the next two years. Pulse is positioned at the upstream extraction layer. As the ecosystem matures, our compiled Skills become more valuable to every downstream tool the team uses. The live demo at [pulsehq.tech](/how-it-works) shows the extraction in action. --- ## How to onboard new engineers in weeks, not months - Satellite 16 - Published: 2026-04-14 - Read time: 7 minutes - URL: https://pulsehq.tech/blog/onboard-engineers-faster - Excerpt: Three friction sources eat the first 60 days of every new engineer. None of them are solvable by writing more documentation. The structural fix changes the question from days to hours. [Figure 1: Two onboarding timelines · an illustrative model] A new engineer joining your team in 2026 takes roughly 60 to 90 days to ship meaningful work. This is the industry norm. Companies optimize their onboarding documents, pair programming schedules, and 30 / 60 / 90 day plans to try to reduce this number. Most efforts produce marginal improvements. A new engineer typically takes 60 to 90 days to ship meaningful work.Teams with institutional memory see new engineers ship in 30 to 45 days.Three frictions: repeated questions, hunting decision rationale, reconstructing project context.The frictions are structural, not solvable by writing more documentation.There is a better path. Teams that build institutional memory into their tooling consistently see new engineers ship meaningful work in 30 to 45 days. The difference is structural, not procedural. This article explains the difference and what to do about it. ## Why traditional onboarding is slow Three friction sources account for most of the 60 to 90 day ramp. **Friction 1: Asking the same questions everyone asked.** New engineers ask senior engineers questions that have been asked before. The senior engineer answers, often by typing the same answer they have typed three times in the last month. Both lose time. The new engineer eventually learns by asking enough questions; the senior engineer gradually becomes less responsive as fatigue sets in. **Friction 2: Hunting for decision rationale.** The new engineer encounters something in the codebase that seems odd. They do not know if it is intentional (with good reason) or accidental (legacy that should be cleaned up). They have to either ask someone or assume one or the other. Wrong assumptions in either direction cause real problems. **Friction 3: Reconstructing project context.** The new engineer is assigned to a project that has been in flight for months. The full context exists across Slack threads, Linear tickets, Notion pages, and meeting transcripts. Reconstructing it takes weeks of part time effort. These frictions are not solvable by writing better onboarding documentation. The documentation gets stale. The documentation cannot capture the actual decision rationale. The documentation cannot reconstruct project context because the context is fundamentally cross tool. These frictions are solvable by structural changes to how institutional memory is captured. ## What structural change looks like When a team has institutional memory captured as a process graph (decisions, commitments, failures as tracked entities), the new engineer onboarding flow changes in three specific ways. **Change 1: The new engineer asks the system, not a senior person.** “Why do we use Postgres over MongoDB?” returns a structured answer: the decision entity with rationale, evidence, and the original Slack thread cited. The new engineer gets the answer in 30 seconds without bothering anyone. **Change 2: Decision rationale is structurally preserved.** When the new engineer encounters the odd looking pattern in the codebase, they can ask “why is this structured this way?” and get the original decision entity. They understand the constraints that drove the design without having to guess or interrupt. **Change 3: Project context is one query away.** “What is the current state of the auth migration project?” returns the structured project history: the original decision, the commitments and their owners, the failures encountered and lessons learned, the recent progress. The new engineer ramps to full context in hours, not weeks. [Figure 2: Time to answer: traditional vs institutional memory] ## The compounding effect The time savings on individual questions add up. If a new engineer asks 50 questions in their first month and each one saves an hour of someone’s time (theirs or a senior engineer’s), that is 50 hours saved per new hire. For a team that hires 5 engineers a year, that is 250 hours of senior engineer time recovered. At loaded engineering cost, that is a meaningful slice of an FTE. But the bigger impact is on the new engineer’s confidence. When they can self serve answers, they feel productive immediately. They stop feeling like a burden on senior engineers. They start asking better questions (deeper, more specific, more valuable) because they have handled the basic ones themselves. This confidence change is hard to measure but enormous in effect. New engineers who feel productive in week 1 stay engaged. New engineers who feel like a burden in week 1 sometimes never recover. ## What this looks like in practice A working example: a new engineer joins on Monday. Standard onboarding includes a single 30 minute session with the engineering manager to set up their tools and explain the company brain (Pulse, in this case). By Tuesday afternoon, they have asked the system roughly 20 questions: how does our auth flow work, why do we use Linear instead of Jira, who handles incident response, what is the deployment process, what is the status of the active sprint. Each answer comes with sources cited. The engineer can dig deeper on anything that needs it. By end of week 1, they have reviewed the active project they will be working on (entire history accessible via the process graph) and started writing their first PR. By end of week 2, they have shipped something meaningful. By end of month 1, they are at full productivity for their assigned scope. > This is not a fantasy. When context stops routing through senior engineers’ calendars, the ramp is paced by the work itself, and the weeks a new hire used to spend recovering context come off the front of the cycle. ## What to do if you are not there yet Three practical steps to reduce onboarding time even without a full company brain. - **Build a structured decision log.** Even a simple list of past decisions with rationale, captured in a single Notion database, beats scattered Slack threads. New engineers can browse it on day 1. - **Document the “who knows what” map.** For each major system in your codebase, identify the 1 to 2 people who know it best. Make this map accessible to new engineers from day 1. Reduces “who do I ask?” friction. - **Schedule context loading time in week 1.** Before the new engineer is expected to ship anything, give them dedicated time to load context: review past decisions, browse active projects, sit in on meetings. The week of investment pays back over the following weeks. These steps help. They do not fully solve the structural problem. The structural solution is institutional memory captured as a process graph: every decision, commitment, and failure preserved as a queryable entity. This is what Pulse provides. Live demo at [pulsehq.tech](/how-it-works). --- ## Why human authored AI workflows always go stale - Satellite 17 - Published: 2026-04-12 - Read time: 7 minutes - URL: https://pulsehq.tech/blog/human-authored-workflows-stale - Excerpt: Three mechanisms drift every documented procedure. Humans adapt to staleness; AI agents execute it literally. The structural fix is workflows extracted from current behavior, not human written specifications. [Figure 1: Why human authored workflows go stale] There is a quiet pattern in every team that builds documented procedures. The procedure is written carefully when first created. It accurately reflects how the team handles the work at that moment. Three months later, it is slightly out of date. Six months later, it is noticeably wrong. A year later, it is actively misleading. Documented procedures are static while team behavior is dynamic, so they diverge by default.Three mechanisms drive drift: tool changes, convention evolution, and personnel changes.A human adapts to a stale procedure; an AI agent executes it literally and fails.Auto extracted workflows stay current by reflecting current behavior and flag drift automatically.This is documentation drift. It happens to every team, in every tool, regardless of the discipline applied to maintenance. The structural cause is that documented procedures are static while team behavior is dynamic. The two diverge by default. This article is about why this matters for AI agents specifically, and what the alternative looks like. ## How drift happens Three specific mechanisms drive documentation drift. **Tool changes.** The team starts using a new tool. The documented procedure references the old tool. Someone updates the procedure, partially. Six months later, the procedure references both tools with inconsistent guidance. A year later, only the new tool is in use but the procedure still references the old one. **Convention evolution.**The team’s conventions evolve naturally. The original procedure said “ping the on call engineer in #incidents.” Eight months later, the team has shifted to using a dedicated incident coordinator role. The procedure still says “on call engineer.” New team members get confused. **Personnel changes.**The senior engineer who wrote the procedure left. Their replacement does things slightly differently. The procedure reflects the original engineer’s approach, not the current one. New team members trying to follow the procedure get different feedback than what is in the document. None of these are correctable through better discipline. They happen because writing comprehensive procedures takes time, and updating them takes even more time, and teams do not have unlimited time. Every team would maintain perfect documentation in an alternate universe with infinite engineering hours. In this universe, drift wins. ## Why this matters for AI agents When you give an AI agent a documented procedure to follow, the drift problem becomes specifically dangerous. A human reading a slightly stale procedure can detect the staleness. They notice the procedure references a tool they no longer use, or a person who no longer works at the company, or a step that does not match current practice. They adapt. An AI agent following the same procedure does not adapt. It executes the documented steps literally. When the documented step references the old tool, the AI agent tries to use the old tool (or fails because it cannot find it). When the documented person does not exist, the AI agent flags an error. The AI agent’s literal execution of stale procedures produces failures that would not happen if a human were doing the work. This is the fundamental problem with human authored AI workflows. > The documentation drift that is tolerable for humans becomes a critical failure mode for agents. [Figure 2: Drift's effect on AI execution] ## What auto extracted workflows change Auto extracted workflows solve drift by inverting the relationship between documentation and behavior. Instead of trying to maintain documents that match behavior, the system extracts current procedures from current behavior. When the team’s actual workflow evolves (they switch tools, change conventions, modify their approach), the extracted Skills evolve with them. The drift detector catches divergence between the current Skill and recent team behavior. When divergence crosses a threshold, the Skill flips to DRIFTED status and the owner is prompted to update it. This is not perfect. Some manual review is still required when patterns change significantly. But the cost of maintenance drops by an order of magnitude because the system catches drift automatically rather than requiring continuous manual review. We covered the full architecture of this in [the Skills cornerstone](/blog/auto-extracted-skills-from-observed-work). The relevant point here: auto extraction does not just save authoring time. It solves the durability problem that human authored procedures fundamentally cannot solve. ## What this means for evaluating AI agent platforms When evaluating AI agent tools, the staleness question is one of the most important and most overlooked. Three specific things to ask. - **How are workflows authored?**If the answer is “humans write them in our editor,” you are inheriting the drift problem. The workflows will be accurate when written and increasingly stale over time. - **Does the system detect when workflows go stale?** Some tools have drift detection built in. Most do not. If the answer is “users update them manually,” in practice that means workflows go stale and stay stale. - **Can workflows be auto extracted from observed behavior?** This is the structural fix to the drift problem. Tools that support auto extraction can keep workflows current without requiring continuous manual maintenance. These three questions are the difference between an agent platform that produces working agents in production versus one that produces impressive demos that fail when the underlying conventions change. ## What to expect Three predictions about the agent platform space over the next 24 months. - **The drift problem will become visible.** As more teams deploy AI agents, the staleness failures will become more public. Early adopters will share war stories about agents that worked great in month 1 and produced wrong outputs by month 6. - **Drift detection will become a standard feature.** Tools that do not have it will look obviously inferior compared to tools that do. Buyers will start asking the question. - **Auto extraction will become a competitive moat.** Tools that can extract workflows from observed work, calibrate against outcomes, and maintain them automatically will significantly outperform tools that rely on manual authoring. Pulse is built around auto extraction from the architecture up. We chose this approach specifically because we believe the drift problem will be the defining feature of agent platforms over the next several years. The Skills compiler we covered in the Skills cornerstone is our investment in this future. If your team is evaluating agent platforms, the workflow maintenance question is one of the most important to ask. Do not let great demos distract you from the long term operability question. Live demo at [pulsehq.tech](/how-it-works). --- ## Atlassian Rovo vs Pulse, choosing team AI for the modern stack - Satellite 18 - Published: 2026-04-10 - Read time: 8 minutes - URL: https://pulsehq.tech/blog/rovo-vs-pulse - Excerpt: Rovo's strengths inside Atlassian are real, and its connectors now reach beyond it. The difference is shape: search hits versus structured decision records. Plus the trust posture change of April 2026. Atlassian Rovo passed 5 million monthly active users in late 2025. It is a significant product with real momentum. For teams running on the Atlassian stack (Jira, Confluence, Bitbucket), Rovo is the natural AI layer. Atlassian Rovo passed 5 million monthly active users in late 2025.Rovo holds Atlassian tools as first-class objects; other tools arrive as connector search.The real difference is shape: search hits versus structured decision records.From August 2026, Rovo collects customer data for AI training by default.But many software teams have explicitly left the Atlassian stack. They chose Linear over Jira. They chose Notion over Confluence. They chose GitHub over Bitbucket. Rovo can index much of that through connectors now; what it holds as first-class objects is still the Atlassian slice, and the rest arrives as search results. This article is about the structural difference between Rovo and Pulse, and how to decide which fits your team. [Figure 1: Stack alignment · Rovo vs Pulse] ## Where Rovo is strong Rovo’s strengths are real and worth respecting. **Bundled with Atlassian Cloud.** Rovo is included with Atlassian Cloud subscriptions. For Atlassian customers, this is effectively free additional capability. Atlassian has used this bundling aggressively to drive Rovo adoption, which is how they reached 5M MAU so quickly. **Deep Atlassian integration.**Rovo understands Jira’s data model intimately. It can answer questions about Jira tickets, Confluence pages, and Bitbucket repositories with high quality because Atlassian built the underlying tools and knows them better than any third party. **Enterprise ready.**Rovo inherits Atlassian’s enterprise security posture, compliance certifications, and admin controls. For enterprises already on Atlassian Cloud, deploying Rovo is operationally simple. **Bundled availability.** Atlassian rolled Rovo into its paid Cloud plans starting in 2025, which significantly lowers the adoption barrier. A team already paying for Atlassian Cloud can try Rovo without additional spend. > If your team is on the Atlassian stack, Rovo is the right choice for in Atlassian AI capability. We are not arguing otherwise. ## Where Rovo’s reach thins out Rovo’s structural limit is shape, not blindness. Its Teamwork Graph connectors now reach well beyond Atlassian, including GitHub, Slack, Google Drive, and Notion, so the old “Rovo can’t see your stack” argument no longer holds. What still distinguishes the two products is how that content is held once it arrives. Three specific limits for modern stack teams. **Linear tickets.**Teams that have moved off Jira to Linear keep their engineering planning, sprint workflows, and individual ticket discussions in Linear, and Linear is not on Atlassian’s connector list as of mid-2026. For a team that left Jira deliberately, that gap covers the bulk of engineering coordination. **First-class versus federated.**Jira issues and Confluence pages are first-class objects in Rovo, with the full Atlassian data model behind them. Third-party content arrives as connector-indexed search material: findable, but not modeled. A Slack debate or a GitHub review surfaces as a search hit, not as part of a decision’s history. **Search index versus process graph.**This is the cornerstone argument and it does not depend on coverage at all: an index answers “where is the document,” a process graph answers “what did we decide, who owns it, and what happened next,” with the rationale and the dissent attached. Indexing more tools does not produce that structure. [Figure 2: How each product holds a modern stack team’s work] ## Where Pulse fits Pulse is built for modern stack teams. Our 25 connectors span the tools modern teams actually use: Slack, GitHub, GitLab, Notion, Linear, Jira, Asana, Google Workspace, Microsoft 365, Salesforce, Stripe, Dropbox, and meeting transcripts. For a team where most work happens in Linear, Notion, GitHub, and Slack, the decisions, commitments, and failures captured by the process graph come from where the work actually happens, kept as structured records rather than search hits. For a team that is still mostly on Atlassian, Pulse and Rovo are different products. Rovo is the right choice for Atlassian native work. Pulse is the right choice if you also need cross tool coverage including non Atlassian tools. For a team that is in transition (some teams on Linear, some still on Jira), Pulse’s broader connector coverage means it can span the transition without leaving teams uncovered. ## The trust positioning difference One additional point worth noting: in April 2026, Atlassian announced that starting August 2026, Rovo would collect customer data for AI training by default. How much of that collection an admin can switch off, and whether it starts switched off, depends on the plan. We covered the implications of this in [the no training cornerstone](/blog/ai-tools-never-train-on-customer-data). The short version: customers who care about no-training commitments need an admin to audit the data-contribution controls on their specific plan, and to keep auditing them as the terms evolve, or use a product where there is nothing to switch off. Pulse made the structural commitment to never train on customer data from the beginning. The training infrastructure does not exist as a separate concept; we would have to build it from scratch to start training. For customers who value this commitment, Pulse provides it structurally. ## How to decide Three questions to clarify which fits your team. **Question 1: Where do your decisions actually get made?** If your team’s work and decision making live in Jira, Confluence, and Bitbucket, Rovo holds them as first-class objects and is the natural fit. If they live in Linear, Slack threads, GitHub reviews, and Notion, Pulse keeps them as structured records rather than search hits. If you are somewhere in between, evaluate based on where you are heading rather than where you are. **Question 2: Are you on Atlassian Cloud already?** If yes, Rovo is bundled at no additional cost. Even with limited coverage, the marginal cost is zero, so trying it is free. If no, getting on Atlassian Cloud just to use Rovo is a major commitment for what would be limited coverage. **Question 3: How much do the trust commitments matter to your team?** For some teams, the data training question is acute. For others, it is tolerable. The right answer depends on your specific data sensitivity and the level of structural commitment you want from your AI vendor. For most modern stack software teams in the 5 to 500 segment, Pulse is the better fit because it models where the work actually happens instead of indexing it. For Atlassian native enterprises, Rovo is the better fit because it covers their specific stack with deep integration. Both can be defended as the right choice for their respective segments. Live demo at [pulsehq.tech](/how-it-works). --- ## The new shadow IT, managing personal AI agents - Satellite 19 - Published: 2026-04-08 - Read time: 8 minutes - URL: https://pulsehq.tech/blog/shadow-ai-agents-companies - Excerpt: Productivity pressure plus consumer priced AI plus capability gaps equals shadow AI agents at every software company. The four categories of new risk, and the three responses that actually help. [Figure 1: The new shadow IT, personal AI agents] There is a phenomenon emerging in software companies that nobody has fully named yet. Employees are deploying personal AI agents that operate on company systems, often without IT knowledge or approval. Employees are running personal AI agents on company data without IT visibility.Three drivers: productivity pressure, consumer-priced tools, and capability gaps.New risk categories: inference exfiltration, unaudited decisions, training exposure, and capability creep.The response with the most leverage is providing a sanctioned alternative, not detection.An engineer runs Claude Code on company laptops using a personal API key, with company source code. A PM uses ChatGPT custom GPTs that ingest internal documents. A sales rep deploys a personal AI assistant that reads from their Salesforce account and reports back to them locally. An operations lead runs an autonomous agent that polls company Slack and surfaces summaries to their personal email. None of this is malicious. The employees are trying to be more productive. But collectively it represents the next wave of shadow IT, with implications most security teams have not fully grasped. ## The pattern Three structural drivers behind shadow AI agent adoption. **Driver 1: Productivity pressure.**Employees are evaluated on output. AI tools demonstrably increase output. When the company’s sanctioned tools are inadequate or slow to roll out, employees use their own. The same dynamic drove the original shadow IT wave when consumer cloud tools (Dropbox, Slack itself) outpaced corporate sanctioned options. **Driver 2: Tool availability.** Powerful AI tools are now consumer priced. A modest monthly subscription gives any employee access to Claude, ChatGPT, or Cursor. The friction to start using them is zero. The decision happens at the individual level without requiring IT approval. **Driver 3: Capability gaps.** Most companies do not yet have sanctioned AI tools that match what consumer tools offer. The IT approved option is often inferior, more restricted, or simply does not exist yet. Employees fill the gap with what is available. The result: every software company in 2026 has a substantial fraction of employees using personal AI agents on company data, mostly unknown to IT, and the percentage is growing. ## Why this is different from previous shadow IT > Previous shadow IT (consumer cloud storage, unsanctioned SaaS tools) created data security issues. Shadow AI agents create those plus new categories of risk. **Data exfiltration through inference.** A shadow agent that reads company data and processes it through an external API has effectively exfiltrated that data. Even if the API provider does not retain it, the data crossed an unmonitored boundary. For companies with regulatory requirements (GDPR, HIPAA, SOX), this creates compliance exposure. **Decisions made by unaudited systems.** A shadow agent that drafts emails, makes recommendations, or executes actions on behalf of an employee is making decisions that affect the business. Without governance, these decisions are not auditable. When something goes wrong, there is no record of how the wrong decision was made. **Accumulated training data risk.**If the employee’s chosen AI provider trains on input data (some do, some do not, opt out policies vary), the company’s data is contributing to that provider’s model. This is the issue we covered in [the no training cornerstone](/blog/ai-tools-never-train-on-customer-data), but at the individual employee level rather than company vendor level. **Compounding capability creep.**Personal AI agents start with read access (“just summarize my emails”). They expand to write access (“draft replies for me”). They expand to action execution (“send the drafts when I am not at my computer”). Each step seems incremental but the cumulative capability is significant. [Figure 2: Four categories of shadow AI risk] ## What companies should do Three responses, ranging from minimal to comprehensive. **Response 1: Acknowledge and document.** Stop pretending shadow AI does not exist. Survey employees about what AI tools they are actually using. Most will tell you if you ask without threat. Document what is in use and start tracking exposure. This is the minimum response. It requires no policy changes and no new tooling. It just makes the problem visible. **Response 2: Provide sanctioned alternatives.** The structural cause of shadow AI is gaps in sanctioned tooling. Close the gaps. Provide AI tools that employees actually want to use, with the governance their work requires. When the sanctioned option is competitive with the consumer option, shadow usage decreases naturally. This is the most leverage response. It addresses the cause rather than the symptom. It also requires real investment in evaluating and deploying enterprise AI tools. **Response 3: Detection and governance infrastructure.** For companies in regulated industries or with high data sensitivity, additional detection infrastructure is warranted. AI traffic monitoring, browser policy enforcement, endpoint visibility, AI specific DLP. This is the most comprehensive response and the most expensive. It is appropriate for high stakes environments but overkill for many companies. The right response depends on your industry, your data sensitivity, and your risk tolerance. Most companies should at minimum do Response 1 and Response 2. Response 3 is for specific contexts. ## Where Pulse fits Pulse is not a shadow agent detection or governance product. We do not sit on the network. We do not monitor employee endpoints. We do not track which AI tools your employees are running. What Pulse does is provide the sanctioned alternative. When your team has access to Pulse (a sanctioned tool with proper governance, ACL inheritance, audit logging, and no training on customer data), the pressure to run shadow agents decreases. Employees who would otherwise use a personal AI agent on company Slack data can use Pulse instead, with proper trust posture. This is the closest Pulse comes to addressing the shadow agent problem: by being the credible sanctioned alternative that reduces the underlying pressure. For full shadow agent governance (detection, DLP, policy enforcement), that is a different product category. Companies like Lakera, Wiz, Cyberhaven, and Cloudflare are building products in that space. The capability you need depends on your specific risk profile. ## What to expect The shadow AI problem will get worse before it gets better. Three predictions. - **The first scandals will hit in 2026 or 2027.** A company will discover that employees were exfiltrating sensitive data through personal AI agents. The story will be public. IT and security teams across the industry will react. - **Governance tooling will mature.** New product categories will emerge specifically for AI agent governance. Some will become important enterprise tools. - **Sanctioned AI tooling will close the gap.** Companies will invest more heavily in sanctioned AI tools to reduce shadow usage. The companies that move fast on this will avoid the worst exposure. For teams thinking about this proactively, the highest leverage move is deploying sanctioned AI tools that employees actually want to use. This addresses the cause. Pulse is built specifically for this purpose at the team coordination layer. Live demo at [pulsehq.tech](/how-it-works). --- ## Calibrated confidence, why your AI tool should tell you when it is unsure - Satellite 20 - Published: 2026-04-06 - Read time: 7 minutes - URL: https://pulsehq.tech/blog/calibrated-confidence-ai-tools - Excerpt: Most AI tools show confidence as absent or fabricated. Real calibration requires outcome tracking, recalibration, and per workspace adjustment. The three questions to ask any vendor. The most underrated capability in AI tools is the ability to say “I do not know.” The most underrated capability in AI tools is the ability to say “I do not know.”Most AI tools sound equally confident whether they are right or wrong.Real calibration requires prediction logging, outcome tracking, and periodic recalibration.The diagnostic: ask a vendor to show a calibration curve from production data.Most AI tools today sound equally confident whether they are right or wrong. The same authoritative tone delivers an accurate answer and a hallucinated answer. The user has no way to distinguish them by the tool’s behavior alone. This is not a minor UX issue. It is the difference between an AI tool you can trust with consequential decisions and one you can only trust for low stakes work. This article is about what calibrated confidence is, why it matters, and what to look for in AI tools you are evaluating. [Figure 1: Confidence as a first class output] ## What calibrated confidence means A calibrated AI tool says “I am 85% confident the auth migration is blocked on Stripe,” and that 85% is real. Across all the times the tool says “85% confident,” it is right roughly 85% of the time. A miscalibrated tool might say “85% confident” when it is actually right 60% of the time, or 95% of the time, or 30% of the time. The number is just a number; it does not correspond to actual accuracy. Calibration is what makes the confidence number useful. When you see “92% confident” on a calibrated tool, you can rely on that number to make decisions. When you see “92% confident” on an uncalibrated tool, you cannot rely on it at all. Most AI tools today are uncalibrated by default. They either do not show confidence numbers or they show numbers that do not correspond to anything measurable. ## Why most AI tools are not calibrated Three structural reasons. **Reason 1: Calibration requires tracking outcomes.** To calibrate, you need to know whether past predictions were right or wrong. This requires the tool to log every prediction, every outcome, and the relationship between them. Most AI tools do not do this. They generate answers and move on. **Reason 2: Calibration requires per domain tracking.** A model that is calibrated overall is not necessarily calibrated for any specific domain. Calibration on questions about engineering decisions might differ from calibration on questions about customer support. Tracking per domain calibration requires segmentation that most tools do not bother with. **Reason 3: Calibration is hard to demo.**In a sales conversation, “we are 80% accurate on questions like yours” does not land as well as “our AI gives confident, detailed answers.” Marketing pressure works against calibration. Vendors prefer the illusion of certainty. The result: most AI tools show confidence as either absent (no number) or fabricated (a number that does not correspond to measured accuracy). Real calibration is the exception. ## What calibrated AI tools enable When confidence is calibrated, three behaviors become possible. **Behavior 1: Selective automation.**When the AI says “92% confident, here is the answer,” you can automate based on that confidence. Actions with 95%+ confidence can auto execute. Actions with 60 to 95% confidence can require human review. Actions below 60% confidence can be flagged for caution. This selective automation is impossible without reliable calibration. **Behavior 2: Informed human review.**When a calibrated AI says “47% confident,” the human knows to dig deeper before acting on the answer. The system has flagged its own uncertainty. The human can spend their attention on the cases that need it. **Behavior 3: Trust over time.**When the AI’s calibration stays accurate over time, users build trust. They learn that the system tells them the truth about its own uncertainty. When the system says “high confidence,” users believe it. When it says “low confidence,” users adjust accordingly. > All three behaviors require calibration to be real, not just claimed. A system that fakes calibration breaks trust the first time users discover the gap. [Figure 2: Calibration curve · predicted vs measured] ## How calibration is actually built Calibration requires three architectural components. **Component 1: Prediction logging.** Every AI prediction is logged with its predicted confidence and a unique identifier. This is the foundation; without prediction logs, calibration is impossible. **Component 2: Outcome tracking.** When users react to predictions (mark them right or wrong via thumbs up or down, take action on them, fail to take action), the outcomes are logged and linked back to the original predictions. This is where most systems fall short; outcome tracking is tedious and product teams often skip it. **Component 3: Periodic recalibration.**A statistical analysis runs periodically (typically daily or weekly) that compares predicted confidence to measured outcomes. When the curves diverge, the model’s confidence outputs are adjusted to match reality. This recalibration happens automatically. For team AI tools specifically, calibration is per workspace and per topic. A model that is calibrated for “engineering decisions” might differ from one calibrated for “customer support escalations.” Each workspace has its own calibration profile that evolves over time. ## What to ask AI vendors Three specific questions when evaluating AI tools. **Question 1: Do you show confidence scores?**A “no” answer means the tool does not expose its uncertainty. Users cannot tell the difference between confident answers and guessed answers. This is a significant limitation for any consequential use case. **Question 2: How are the confidence scores calibrated?** The right answer involves measurable processes: outcome tracking, statistical recalibration, per domain or per workspace adjustment. The wrong answer involves marketing language: “we use advanced techniques,” “our model is highly accurate,” “trust our judgment.” **Question 3: Can you show me a calibration curve from your production data?** A vendor that has actually invested in calibration can show you the data. The curve might not be perfectly diagonal, but it should be close. A vendor that has not invested in calibration will deflect this question. The third question is the diagnostic. Vendors who can show real calibration curves have done real work on this problem. Vendors who cannot have been faking it. ## Where Pulse fits Pulse tracks calibration per workspace, per topic. Every Skill invocation logs its predicted confidence and the eventual outcome. Periodic recalibration adjusts the confidence outputs to match measured accuracy. We expose calibration data to admins who want to see it. This is not a marketing claim. The calibration infrastructure is part of the architecture, not bolted on. We made this investment because we believe AI tools that can honestly express uncertainty will be the long term winners. Tools that maintain false confidence will eventually be caught by their first major failure. For teams thinking about AI tools they can actually trust with team level decisions, calibrated confidence is one of the most important and most overlooked capabilities. Do not accept “we are accurate” as an answer. Ask for the curve. Live demo at [pulsehq.tech](/how-it-works).