Should you build your own customer context layer or buy one?

The short answer. Build the parts of a customer context layer that are specific to your business, like your skills, agent instructions, definitions and workflows, and buy the shared infrastructure under them: ingestion, per-person permissions, identity resolution and agent governance. If you are the only person who will use it, building all of it yourself is a reasonable project of a few weeks, and the moment a second person, or an agent working for them, needs it, the infrastructure becomes the project.

You can start it yourself, and the first version will probably work. Finishing it for a team is a different job with a different owner, and that job is the one to price before you commit.

Most build-versus-buy advice for this question is about customer data platforms, which unify product and marketing events into profiles. This guide is about the context a go-to-market team and its agents need: the email threads, calls, meetings and Slack messages behind every deal, linked to the people, companies and deals they involve. For how such a layer is built, step by step, see How to build your own context graph.

---

What you are deciding

A customer context layer is several pieces, and each one is its own build-or-buy call. Some are infrastructure every company needs in the same form. Others are what make your go-to-market different.

Piece	What it does	Usually
Ingestion	Pulls email, calendar, meetings, Slack and CRM data, continuously	Buy
Permissions	Decides who, and which agents, may see each thread, transcript and message	Buy
Identity resolution	Makes the same person or company one record across every source	Buy
Storage and retrieval	Keeps the full text and the links, and answers agent questions with sources attached	Buy
Agent governance	Runs agents as their person, records what they did, lets you fix a skill	Buy
Skills and agent instructions	The work your agents do, in your words	Build
Definitions and fields	What counts as a qualified deal, a churn risk, a competitor	Build
Workflows and internal apps	Your process, your reports, your tools	Build

The test for "buy" is the one engineering teams already use. Is the piece hard, is it the same at every company, does it carry security and compliance weight, and will it need maintenance for as long as the business runs? Ingestion, permissions, identity, retrieval and governance pass all four. Skills and definitions fail the second, because they are what makes your team yours, so keep them in your hands whichever way you go.

---

When building it yourself is the right call

Plenty of teams should build, at least at first. Building is the right call when:

• You are the only user, and will be for months. One person's inbox, transcripts and CRM export is a contained problem.
• You don't yet know the questions. A small build is the fastest way to learn what your team actually asks, and that list is the best thing to bring to any vendor evaluation.
• Customer context is your product, so the way you model and retrieve it is part of what you sell.
• You have rules no vendor can meet, such as data that can't leave your infrastructure.
• A platform team will own it permanently, with a named person whose job includes it next year, not engineers fitting it in between other work.

How to scope a build

Keep the first version small enough to finish, and decide in advance what would make you revisit the decision.

1. Write 10 to 20 questions it has to answer, in your team's words.
2. Pick three sources: your own inbox, your call transcripts and a CRM export.
3. Store them in Postgres with pgvector, with a source ID and timestamp on every fact.
4. Expose three tools over MCP, such as get_account_context, search_conversations and get_timeline, and connect Claude Code.
5. Grade it on 20 questions with known answers.
6. Timebox it to a few weeks, and write down the trigger for revisiting: a second user, a second inbox, or an agent that sends anything to a customer.

That version will work well for you. The questions, skills and definitions you work out while building it carry over if you later stand them on something else.

---

Where homemade builds stall

The week-one version works because it has one reader. The hard parts arrive with the second one, and builders who hit them usually name them before any vendor does.

Email and permissions. Notes and call recordings go into a homemade index easily. Email does not, because once it matters who may see what, each person's sharing rules have to be applied as each message arrives, before a summary or embedding can carry a private thread to someone else. Reading Gmail also takes a restricted scope. An app with users outside your own Google Workspace has to pass Google's verification and a security assessment by a Google-approved third party, repeated at least once a year, and until it is verified it is capped at 100 users.

Deployment. What took you weeks to shape for yourself has no path to the rep who will never touch a terminal. Reaching that person means delivery in Slack or email, a view of what their agents did, and a way to fix a skill when it misfires. That is a second product, built on top of the first.

Drift. Your business changes faster than your schema and your prompts. A skill tuned for last quarter's pipeline keeps running against this quarter's, and nothing in a homemade rig tells you its output got worse.

Evaluation. Once agents draft emails and update deals, you need a record of what each one did, on what evidence, and how good it was. Without one, you hear about a bad draft from the customer who received it.

None of this means a serious team can't build it. Teams do, often. Day AI tracks the competitors on its own deals as free text, and when the company looked at what its agent had captured across those deals, the most common competitor wasn't a company. It was teams deciding to build it themselves. Some of those teams came back two or three months later.

Finishing costs more than starting, and when a homemade layer fails, the cost lands outside the engineering team: on a customer who got an email written from stale data, or a colleague who saw a thread meant for someone else.

So the case for buying the core starts when any of these is true:

• A second person needs it, especially someone who will never open a terminal.
• It has to hold email from more than one inbox.
• Agents will act for other people, drafting emails, updating deals or briefing reps.
• Nobody owns it a year from now. A layer without a permanent owner degrades, and nothing in it will tell you.
• You need it this quarter. Ingestion, permissions and identity are each a project before the first useful answer.

Before and after shows the same question answered two ways: by Claude wired to a separate MCP connector for every tool, and by Claude on one context graph.

---

What each path costs over 6 to 12 months

Every team's numbers differ, so treat this as a worksheet. Fill in your own figures, count the one-time lines once, and multiply the monthly lines by the months you are planning for.

Building it yourself

Line	How to estimate it	Your number
First version	Weeks × people × loaded weekly cost
Each additional source	Setup weeks, plus monthly hours to keep the sync running
Team email permissions	Design and build time, plus Google verification and the annual assessment if the app serves users outside your Workspace
Freshness and on-call	Monthly hours on expired tokens, stopped jobs, changed APIs and backfills
Identity resolution	Monthly hours reviewing merges and fixing wrong ones
Deployment for non-technical users	Build time for delivery, visibility and skill editing, plus upkeep
Evaluation and skill upkeep	Monthly hours keeping test sets and prompts current
What the team didn't build	The work these hours would otherwise have gone to

Buying the core

Line	How to estimate it	Your number
Agents	Price per agent × number of agents × months (see pricing)
Setup	Time for each person to connect email and calendar and set sharing rules, then the first sync
Skills and definitions	The same work as in a build. You write these either way
CRM and other tools	If you keep Salesforce or HubSpot, time to connect their MCPs and write the skills that keep stages, notes and fields current

For Day AI specifically, the public prices per agent per month are Turbo $30, Professional $75 and Executive $250, or $24, $60 and $200 billed annually, with volume discounts above 20 agents and no usage-based pricing. Teammates on Free seats cost $0, but Free seats exist only in a workspace with at least one Professional agent or higher. MCP access comes with every agent from the Turbo tier up, some tools are reserved for higher tiers, and a new person's first email and calendar sync takes one to six hours.

One cost fits in neither table: what a wrong email to a customer, or a private thread shown to the wrong person, would cost you. In a build, preventing it is your code. In a purchase, it is the first thing to check.

---

A checklist for the decision

Answer each question yes or no.

1. Will more than one person read from it in the next six months?
2. Will it hold email from more than your own inbox?
3. Will agents draft, send or update anything on someone else's behalf?
4. Will anyone use it who won't open a terminal?
5. Is there a named owner whose job includes running it a year from now?
6. Is customer context itself part of what you sell?
7. Do you have data rules that no vendor can meet?
8. Can you write down the 10 to 20 questions it has to answer?

Reading the answers. Each yes to questions 1 to 4 is a reason to buy the core. A yes to 5, 6 or 7 supports building, and a build only lasts with a yes to 5. A no to question 8 means start with a small build or a trial to find the questions, whichever way you lean.

If you are evaluating vendors, ask each one these, in writing:

• Are each person's email sharing rules applied when mail arrives, or filtered when someone reads it?
• Do agents run with the permissions of the person they work for?
• Does every answer cite the email, call or message it came from?
• Can a field you add today be filled from last year's conversations?
• Can your own tools reach the data over MCP or an API, and what does that cost?
• What will you still have to build yourself, such as the sync to your CRM?

---

Buy the core, build on top

Most teams end up doing both. They buy the context graph and the agent control plane, and build their skills, definitions, workflows and internal apps above them. Buying the core is what frees a team to build ambitiously on top, so the safe choice and the ambitious choice turn out to be the same one.

Day AI provides the context graph and agent control plane to quickly and securely upgrade your company brain. Against the vendor questions above:

• Email arrives with each person's rules applied. Each person connects their own Gmail and Calendar and sets sharing rules by domain, address or Gmail label. Day AI decides who can see each thread as a step in ingestion, and one private message keeps its whole thread private. Email in the graph comes from Google Workspace today. Outlook, Outlook Calendar and Teams are reachable live through connectors in beta.
• Agents act as their person. An agent inherits the permissions of the person it works for. For Salesforce and HubSpot, your company registers its own OAuth app and each person connects with their own account.
• Answers cite their sources. An answer links to the call clip or message it came from, and every value keeps a history of who changed it, when, why, and what it was derived from.
• New fields fill from history. A custom property starts from a definition an agent follows and is backfilled across every conversation already in the graph.
• Your tools stay. Your folder, skills and Claude Code connect to the graph over MCP, with OAuth, at https://day.ai/api/mcp. day.ai/mcp covers setup for Claude, Claude Code and Cursor, and the MIT-licensed Day AI SDK is a TypeScript client for the same tools.
• Your other tools connect over MCP. Day AI supports connecting MCP servers. Your agent reads from any server you connect, and if the server supports writes, it writes to it when you ask, or a scheduled skill does it on a cadence. Connect the Salesforce or HubSpot MCP and you get two-way sync: a skill can update deal stages, notes and fields after every call, or pull CRM data into the graph on a schedule. Each person connects with their own login.
• What you still build. Your skills and definitions are yours to write, and every skill keeps a history of its runs. When one misfires, you tell the agent, it shows you the skill's definition, you change it, and later runs use the change. Day AI's own marketing team keeps its skills in a Claude Code repo connected to Day AI over MCP, where its agents look up people, companies and deals, write pages and run campaigns.

To see how your current build measures up, the public company-brain-evaluation skill runs in your folder (npx skills add day-ai/company-brain-evaluation), scores it on safety, performance, capability and adoption, and writes up what building the rest yourself would take.