Before building a context graph for sales

Who this guide is for

Who this guide serves. You built the agents. They run. A renewal agent drafts the right email, a call-prep skill assembles the right brief, a deal-review copilot answers the manager's question. What you cannot yet show: that the agent picked the move the CRO would have picked, that the rep acted on it, and that the deal moved because of it. This guide serves the engineer who owns that gap.

Target User of the Guide: AI GTM engineers build and maintain sales agents. They scope or evaluate context graphs.

Out of Scope: Sales leaders and revenue owners manage sales strategy rather than technical stacks.

The guide serves two moments. In the mid-funnel evaluation, you hold a shortlist and need criteria that a demo cannot fake: Sections 1 through 3 and the scorecard in Section 9. In the late-stage build-versus-buy decision, you hold a budget request and need the work breakdown, the maintenance burden, and the tests that would prove either path: Sections 4 through 8. The FAQ and glossary serve both.

The RevOps counterpart and the CRO read other Zime guides. This one stays on the engineering side of the line, with one exception: adoption, because the pages make adoption an engineering deliverable with an event model, and because the CRO's question at day 90 lands on your desk.

Context graphs prevent sales agents from guessing account history. Engineering teams deploy graph stores, connectors, and retrieval systems within a quarter.

Effective retrieval alone fails. Agents access account history, but lack critical governance context:

Answering these questions requires ongoing operational infrastructure beyond retrieval. Teams need versioned strategy models, exception testing, performance telemetry, and long-term ownership.

This guide outlines operational costs. It provides evaluation benchmarks for assessing external vendors, including Zime.

Zime wrote this guide. Every claim carries a tag: [V] for claims Zime publishes on named product pages, [M] for figures from the GISTICS planning model, and UNSOURCED for unsupported claims. GISTICS operates as an independent research firm and provides assumptions on request. The guide highlights conditions where building in-house succeeds.

Why read this guide?

What does the in-house build cost once it has to stay right?

The graph you were asked to build is the cheap part. Six costs follow it, listed in the order they reach the person who owns the build.

1. You inherit a maintenance tail that grows with scale. In the planning model, recurring labor runs about a third of the original build hours every year at pilot scale and close to half at enterprise scale, before any feature request [M]. The CRO's priorities move each quarter. The competitor set moves. The product moves. A layer nobody refreshes peaks the day it ships, and six months later the agents run last year's plays on this year's model. Section 4.

2. The scope grows faster than the graph. Per-team and per-rep variants arrive early: forty reps, forty harnesses, and no owner of the differences between them. A full deal-motion library, the thing sales leadership will ask for next, adds about 10,336 build hours and 1,498 upkeep hours per quarter in the model's stress test [M]. Decide whether that library sits in scope before the estimate goes to anyone. Section 4.

3. Most of the hours fall outside engineering. Of about 6,900 build hours at pilot scale, engineering roles (data and integration, AI and ML, workflow, SRE) account for about 2,700 [M]. A CRO subject-matter expert and a data steward take about 1,400 more. A knowledge architect and an evaluation analyst, two roles most agent teams never staff, take about 1,700. Your schedule depends on a sales leader's calendar and on evaluation work your team will want to defer.

4. Internal builds stall at the same point, and the stall sits where the risk lives. Most builds reach per-rep variants and a named owner, then hold. The work that rarely gets built: evals that cover exceptions, regression testing on model and context changes, telemetry that joins executed behavior to CRM outcomes, and authority enforced per motion rather than per agent. Those four carry the controls that security, finance, and the CRO each ask for. The guide maps all eleven waypoints so you can locate your own build. Section 4.

5. The build outlives your ownership of it. The owner of record has a product to ship, so the change process turns into a backlog. The refresh loop, the last waypoint, goes unbuilt because the team that built the first six has moved on. Plan the handoff before you plan the schema. Section 4.

6. Evidence takes quarters, and the questions land on you first. The planning model puts a pilot-scale build at five calendar months, a department build at nine, and an enterprise build at fifteen [M]. Meanwhile security asks how an agent gets stopped from committing the company to terms, finance asks what each agent cost, and the CRO asks at day 90 whether deals moved. A build that cannot answer from a trace answers from a slide. Compare that clock with the 21-day first gate the guide tells you to demand of any vendor on your own pipeline [V: DevOps for RevOps]. Sections 1, 6, 7.

For the conversation with finance. The planning model prices a pilot-scale build at about $843,000 up front and about $1.63 million over three years at base case, inside a range of $1.09 million to $2.92 million [M]. These run as planning ranges anchored to BLS wages, not vendor quotes. Replace the rates and hours with your own before anyone funds anything.

When building wins. Build when this layer forms a durable differentiator for your company, when the business will fund continuous strategy and evaluation work, when you hold strong behavioral ground truth, and when connector, policy, and adoption maintenance fit your roadmap [V: DevOps for RevOps]. Section 4 lists the full conditions. Section 9's scorecard works on your own build as well as on any vendor's.

How to use this guide

Where are you in the decision?

Ten sections and a glossary. Read in order or start at your row.

Bringing in your platform owner or security reviewer? Section 7 speaks to them directly. Section 10 answers the nine questions engineers ask most, each in one sentence first.

Three terms you will meet early. Enterprise Sales Harness: the governed runtime and control plane that runs every rep, team, and agent harness from one hub [V: Enterprise Harness]. Zime Workbench: the environment where engineers encode, test, and ship that judgment before release [V: Workbench]. Capability package: the versioned unit you ship, evaluate, promote, and roll back [V: AI Engineers]. The glossary holds the rest.

When you would rather test the claims than read about them, ask Zime for a Proof of Value conversation. Expect one revenue priority, your live pipeline, a baseline set before deployment, and a go, revise, or stop decision at about three weeks, with no revenue guarantee [V: Deployable Capabilities].

Section 1 starts with the failure you have probably already seen: an agent that runs correctly and still picks the wrong move.

The problem you are solving

Why does an agent that runs correctly still pick the wrong move?

Three checks pass. The agent authenticates, retrieves the account, and returns a fluent recommendation. Zime's primer frames the state as three checks passing while eight decisions go missing [V: DevOps for RevOps]. Here are eight an engineer will recognize: which CRO priority governs this deal this quarter, which behavior comes next for this role at this stage, how much authority the agent holds, what evidence must exist before it acts, who approved the rule it followed, which version of that rule ran, whether the rep did what it recommended, and whether the deal moved afterward. The primer calls this state "technically live, behaviorally wrong" [V: DevOps for RevOps]. Retrieval and models reconstruct what happened. They do not decide which priority applies, which behavior follows, or how much authority the agent should carry.

The engineering symptoms, as the Enterprise Sales Harness page lists them [V: Enterprise Harness]:

• Reps and teams build one-off harnesses with no clear owner.
• Skills get copied, edited, and overwritten, and drift from the strategy.
• Inference cost (models, tokens, MCP calls) shows up only on the bill.
• Compliance claims lack evidence: prompts run without policy checks, agents run without guardrails.

You have seen all four. The first two describe every skill library older than a quarter. The third describes every agent whose cost you reconstruct from invoices. The fourth describes every security review where the answer to "how do you prevent an agent from committing us to terms" came from a slide.

The instinct to fix this with a better harness runs correct and stops short. A harness written once and copied to every rep peaks on the day it ships. The strategy changes, the competitor changes, the product changes, and the harness does not, because nobody measures it and nobody owns keeping it current. Six months later the reps run last year's plays with this year's model.

What you buy, when you buy a behavior layer, differs from the content. You can write the content. You buy the lifecycle that keeps the content true, the evaluation that blocks a bad release, the authority model that bounds the agent, the trace that answers the auditor, and the telemetry that answers the CRO. Judgment should get the same lifecycle as code: a package, tests, a release process, and scheduled maintenance [V: Workbench]. Zime names the discipline DevOps for RevOps [V: DevOps for RevOps]. The name tells you the shape of the thing under evaluation, and the shape tells you what to test.

What you are evaluating

Where does the judgment layer sit in a stack you already run, and what does it consist of?

Zime positions itself as a judgment-and-behavior layer above your existing agent stack. If you have built, or been asked to build, a context graph, this layer sits on top of it: the graph supplies what happened, and the layer decides which priority applies, which behavior comes next, and how much authority the agent holds. You keep your models, frameworks, agents, connectors, and data, and add one layer above them [V: AI Engineers]. Identity, environments, model selection, and release approval stay with you [V: AI Engineers]. The layer connects to internal and customer-built agents and to enterprise systems through MCP, with permissions preserved, and delivers into the CRM, Slack, or Microsoft Teams rather than a new interface [V: Enterprise Harness]. It also delivers into CI/CD pipelines [V: Workbench]. Zime describes the layer as model-neutral and framework-neutral [V: DevOps for RevOps]. Private Deployment runs it on hardware you control [V: Enterprise Harness].

Two products, one lifecycle

Zime splits the layer into a pre-release environment and a post-promotion runtime. Workbench covers encode, package, and evaluate. The Enterprise Sales Harness governs what happens after promotion: propagating releases to every harness and observing use and cost [V: Workbench]. The lifecycle runs encode, package, evaluate, promote, propagate, refresh, with roll back or retire when a release fails or a motion ends [V: AI Engineers]. A gate sits between evaluate and promote; a change that fails its Judgment Evals does not reach the field [V: AI Engineers].

Three products run on the harness: Behavior Graph for Sales, CRO Initiatives, and Programmatic Adoption [V: Enterprise Harness]. The Behavior Graph links strategy, selling situations, buyer roles, products, competitors, evidence, behaviors, and results [V: DevOps for RevOps]. Each capability combines a reusable Zime foundation with your strategy, culture, tribal knowledge, and operating context [V: Deployable Capabilities]. Humans review and approve all encoded judgment [V: Deployable Capabilities].

Deployable unit

An engineer ships capability packages. At runtime, a package resolves a Deal Motion for one deal, role, and moment [V: AI Engineers]. The Deployable Capabilities page lists seven parts in a package [V: Deployable Capabilities]:

1. Behavior or skill definition
2. Link to the supported strategy
3. Prompts, source documents, and structured context
4. Workflow and integration configuration
5. Conditions and exceptions, with evidence
6. Evaluation and regression routines
7. Metadata for ownership, release, version, and freshness

Zime's primer specifies a larger object, the Governed Deal Motion Package, with eleven parts: identity, trigger, strategy, behavior, context contract, evidence contract, authority, evaluations, telemetry, exceptions, and rollback [V: DevOps for RevOps]. Read the seven as what the product page says ships and the eleven as the specification to test a shipped package against.

Four parts of the eleven have no named home in the seven: trigger, authority, telemetry, and rollback. Ask Zime to open a package and point to each. A package that carries its authority and rollback inside itself behaves differently under incident than one whose authority lives in a separate policy table and whose rollback lives in a runbook. Acceptance tests 6, 7, and 8 in Section 6 exercise exactly this.

Authority, bounded per package

Central policy assigns every agent one of four guardrail states: Recommend (a person decides), Act (policy allows it), Escalate (hand to a manager), and Request approval (pause until approved). No harness sets its own [V: Enterprise Harness]. The primer adds an authority ladder with three levels and evidence gates between them: Copilot (the system recommends, explains, cites evidence, and drafts; a person decides and acts), Semi-autonomous (bounded steps after approval or within narrow policy rules), and Autonomous (executes the approved motion within explicit limits and escalates exceptions). Authority attaches to the package, not to the agent [V: DevOps for RevOps]. In live deals, Zime guides and the person acts [V: Enterprise Harness].

For an engineer who has wired an agent framework's tool permissions by hand, the distinction matters. Authority on the agent means every new skill inherits the agent's reach. Authority on the package means a renewal motion can run at Recommend while a scheduling motion runs at Act, on the same agent, with the state set centrally and changed without a redeploy. Test it: acceptance test 6 promotes one package, simulates a threshold breach, and expects authority to fall automatically or through a named control path.

What a trace looks like

The AI Engineers page shows a decision trace, an illustrative example rather than a customer record [V: AI Engineers]. A RevOps user asks why the renewal agent recommended a two-year term on an account. The trace answers in four parts: the package ("Renewal: multi-year at risk. Version 4, promoted 12 days ago"), the authorizing priority (a Q3 priority to protect renewals with multi-year terms, approved by the CRO by name), the evidence (usage up two quarters, budget confirmed on the last call), and the result (recommend only; the rep adapted the draft and sent it; the buyer asked for a two-year order form).

That trace carries the whole evaluation. Package version. Authorizing strategy with an approver. Evidence cited. Guardrail state. Human action. Buyer response. If a vendor's trace stops at "the model said," you have a log, not a decision trace. Acceptance test 8 demands that a runtime action resolve back to its package version, strategy, inputs, evidence, permission, result, and downstream signal.

The trade-off cascade

Which decisions bind first, and what does each one rule out?

Thirteen trade-offs, in the order they bind. Resolve them out of order and you will compare vendor features before you have decided what kind of thing you are buying. For each trade-off the guide gives the question, what to look for and ask, and Zime's position with its tag, including where Zime does not fit.

Frame: what kind of thing is this?

Fit: does it match your organization and your stack?

Delivery: how does it run in production?

Economics and risk: what you prove, what you control, what you keep

Reading the cascade

If you resolve Trade-off 1 as content, stop here; a skill library and your platform owner's time will do, and nothing below applies. If you resolve it as lifecycle, Trade-offs 2 and 3 tell you whether a given vendor has one.

Trade-off 4 tells you whether it costs you the stack you built. Trade-offs 5 to 7 tell you whether it will carry your judgment and bound your agents. Trade-offs 8 to 10 decide how it runs and who runs it. Trade-offs 11 to 13 decide what you prove, what you control, and what you keep. The scorecard in Section 9 weights the ten criteria that fall out of this order.

Build ceilings

How far does an internal build get before it stops improving, and what does it cost to hold it there?

A capable AI engineering team can build a first behavior layer in a quarter and should not let a vendor talk it out of trying. The question runs differently: how far does the build get before it stops improving, what does it cost to keep it there, and what does your team not ship while it does. The eleven waypoints below describe what an internal build passes in order. The ceiling sits where the waypoints stop.

Most internal builds reach waypoint 5 or 6 and hold there. That marks no failure of the team; it marks what a static artifact does.

The ceiling sits between waypoints 7 and 11: evaluation that covers exceptions, regression on change, behavior joined to outcomes, authority bound to the motion, and a refresh loop with an owner.

Zime's primer frames acceptance test 9 around the same list: the work breakdown comparison must cover data, schema, evaluations, approvals, telemetry, adoption, and ongoing maintenance, not integration alone [V: DevOps for RevOps].

What the build costs, in hours and months

GISTICS, an independent research firm, built a planning model for the customer-built equivalent of this layer: six sales-execution entities (customers, products, competitors, reps, a deal motion library, and forward-looking CRO strategy), the bindings between strategy and context that require distinct behavior, the workflows that deliver them, and the verification and adoption program around them [M: GISTICS Behavioral Graph Cost Model, 22 Sep 2026].

The figures below are planning ranges with BLS wage anchors, not vendor quotes or implementation benchmarks. GISTICS makes the model's assumptions available on request. Replace the rates and hours with your own before anyone funds anything. The model's own instruction: run a four to six week discovery estimate before funding production.

Where the hours go, base case, by role [M]:

Read the role table before the total. Engineering roles (data and integration, AI and ML, workflow, SRE) account for about 2,700 of the pilot's 6,900 hours [M]. The CRO subject-matter expert and the data steward account for about 1,400.

The knowledge architect and the QA and evaluation analyst, roles most agent teams do not staff, account for another 1,700. The build does not stall on code. It stalls on the hours of a sales leader's time that encoding demands, the evaluation discipline that most teams defer, and the maintenance share that climbs with scale: a third of the build each year at pilot scale, half of it at enterprise scale, before any new feature request.

The model's interpretation, in its own words: labor, integration, judgment encoding, and evaluation dominate list-price infrastructure; buying software does not remove source mapping, CRO decisions, validation, or adoption; CRO strategy behaves as a policy and judgment layer that requires executive ownership and periodic re-approval, not as an ordinary master-data entity [M].

Dollars, once

For the engineer who must hand the case to finance. Base case, USD, three-year horizon [M]:

The model carries a separate stress test for a 500-motion deal library at 10,336 initial hours and 1,498 upkeep hours per quarter, kept apart from the core figures to avoid overlap [M]. Decide whether a full library sits on day one, staged, consolidated, or excluded before the number enters a budget.

What a vendor removes, and what you keep either way

The same model carries a responsibility matrix that an engineer can use to interrogate any vendor, Zime included [M]:

Hold Zime's shared control table (Section 7) against this matrix. Where Zime says the enterprise holds identity, environments, model selection, release approval, tool credentials, and deactivation rights [V: DevOps for RevOps], the matrix says the same work stays yours under any vendor. Where Zime says it holds the Behavior Graph schema, strategy-to-behavior mapping, package versioning, behavioral evaluations, telemetry, and rollback mechanisms [V: DevOps for RevOps], the matrix names the lock-in risk to price: vendor-specific domain representation and incomplete evidence export. Ask for the export format of packages, evals, and telemetry before you sign, not after.

When you should build anyway

Zime's own primer names the conditions [V: DevOps for RevOps]. Build when revenue behavior infrastructure forms a durable product differentiator for your company; when the enterprise will fund continuous strategy and evaluation work; when you hold strong internal ontology and behavioral ground truth; and when connector, policy, and adoption maintenance fit your roadmap. The AI Engineers page adds the three costs of building: opportunity cost, technical debt, and adoption risk [V: AI Engineers]. To those add two from this guide: build if your sales motion resembles no other, so a vendor's foundation gives you little; and build if your data boundary forbids any vendor-supplied schema, even under Private Deployment. In those cases, build, and run Section 9's scorecard on your own build once a quarter.

When the ceiling costs more than the subscription

Use the Zime harness, by the primer's own list, when you want to keep your AI stack and control plane; when internal agents need current, company-specific revenue judgment; when you want to prove one motion before expanding; when behavior, adoption, and deal movement must show up in telemetry; and when lifecycle burden matters as much as initial build effort [V: DevOps for RevOps]. In this guide's terms: buy if you are past waypoint 5 and stalled, if the CRO has changed priorities since the layer went in and the layer has not changed, or if your board asks what the AI spend produced and the answer counts logins.

Choosing your delivery path

How much of the encoding, integration, and adoption work does your team carry?

Every path delivers the same governed package; the paths differ in who does the work around it [V: Deployable Capabilities]. Customers do more under DIY and less under DIFY. Zime provides a Forward-Deployed Engineer or a partner; the customer's team, Zime FDEs, and partners deliver in a mix that depends on the path [V: Deployable Capabilities].

Roles on your side vary by page: AI Platform Owner, GTM Engineer, RevOps, and Security Reviewer for the harness [V: Enterprise Harness]; AI or GTM Engineer, DevOps, and Platform Owner for Workbench [V: Workbench]; Capability Owner, AI or GTM Engineer, and Executive Sponsor for a Proof of Value [V: Deployable Capabilities]. Whatever the path, the pages ask you for a named control-plane owner, your MCP permission and security specs, access to CRM, call, and data sources, evaluation in your own environment, and monthly or quarterly freshness reviews [V: Enterprise Harness; Workbench].

Pricing: UNSOURCED. No page states subscription, path, or FDE pricing. Ask.

A selector

Answer four questions.

1. Do you have a platform owner with capacity to own the control plane and the 90-day plan? No: Co-Implementation or DIFY. Yes: continue.
2. Has the CRO's strategy changed in the last two quarters, or will it in the next? Yes: at least DIWY, because encoding under a moving strategy demands the paired sessions. No: continue.
3. Does the first motion touch a surface your team has not integrated (a CRM object, a call platform, a Teams channel)? Yes: Co-Implementation for the first package; the FDE does the integration once, in your environment, and your team keeps it. No: continue.
4. Is there a board or CEO deadline for showing execution? Yes: DIFY. No: DIY, and move to DIWY the first time the strategy moves.

What to demand as proof

What would have to run, on your pipeline, before you expand scope or authority?

Do not accept a proof of concept. A proof of concept shows that the layer runs. Demand a Proof of Value: a bounded engagement on one strategic revenue priority, with a baseline set before deployment, run on the live pipeline, ending in a go, revise, or stop recommendation [V: Deployable Capabilities]. Zime targets about three weeks: week one for setup and baseline, week two for live deployment and review, week three for assessment [V: Deployable Capabilities]. The proof requires eligible users, a working GTM-agent prototype, active opportunities, deal and conversation evidence, an executive sponsor, and a partner or FDE in the environment [V: Deployable Capabilities].

The primer formalizes the proof as two gates [V: DevOps for RevOps].

Gate 1: one package in production-adjacent conditions, 21 days

Prove that one Governed Deal Motion Package runs against customer-owned data in a production-adjacent environment, with evaluations, approvals, telemetry, and rollback [V: DevOps for RevOps]. Readiness comes before day one. Then: define and connect (days 1 to 5), evaluate (6 to 10), integrate and approve (11 to 15), deploy and prove (16 to 21).

Exit criteria: a named package version in the target environment; authorized data flowing; passing evaluations; approvals bound to the deployed version; traces showing provenance and authority; at least one verified end-to-end behavior; a tested exception and rollback path; documented ownership [V: DevOps for RevOps]. Acceptance test 10 requires that the named enterprise owner can observe and accept every criterion.

Gate 2: adoption, behavior, and movement, 90 days

Assess three things against a baseline or comparison cohort: adoption (eligible users receive, use, and keep using the motion), behavior (the targeted behavior rises, evidence precedes action, prohibited behavior falls), and business movement (buyer response, stage progression, and movement against the baseline or cohort). Before the proof starts, set thresholds for adoption, behavior execution, quality, buyer response or deal movement, exception rate, and operating cost, plus the conditions for expanding scope or autonomy.

Eleven acceptance tests

Zime publishes these in its primer [V: DevOps for RevOps]. Run them on any vendor and on your own build. A vendor who wrote the tests and then fails one in front of you has told you something; so has one who refuses to run them.

Tests 1 through 8 run inside Gate 1 once the package exists. Test 9 runs before you commit to either path; Section 4 supplies the work breakdown. Tests 10 and 11 close the two gates.

Zime's published figures, and how to read them

Five pages carry the same figures: 1,200+ GTM behaviors trained with 50K+ human-in-the-loop hours; about 5 minutes to go live; 80 percent of reps running behaviors in 90 days, resulting in a 20 percent uplift in deals won [V: Enterprise Harness; Workbench; AI Engineers; Deployable Capabilities; Programmatic Adoption]. No page states the sample, baseline, period, or attribution method behind them. The primer says so itself: public Zime outcome metrics carry the label Zime-reported; the 21-day and 90-day proofs stand as proposed verification gates and do not guarantee customer results; establishing revenue causality requires a measurement design that accounts for cohort selection, timing, strategy changes, seller behavior, buyer response, and other confounders [V: DevOps for RevOps]. The Programmatic Adoption page adds that Zime makes no promise of revenue and that each customer builds its own business case from its own baseline [V].

Read the figures as the bar Zime sets for itself, and make Gate 2 the instrument that tests it on your floor. The illustrative scale recommendation on the Deployable Capabilities page shows what the instrument reports: 25 eligible reps, 22 active, 18 who executed the behavior, 26 of 41 deals advanced a stage, 7 reps not yet reached, 0 reps executing at baseline [V: Deployable Capabilities, illustrative]. Four numbers at four levels, with the baseline stated. That shape, not the 80 percent, carries the claim.

Claims you should discount

Discount any adoption figure counted in logins, seats, or tokens. Discount any eval result produced on the vendor's scenarios in the vendor's environment. Discount any trace that stops at the model's output. Discount any uplift figure from a customer whose motion resembles none of yours. Discount Zime's four figures above until Gate 2 reproduces their shape on your pipeline. A buyer's guide that cannot discount its own vendor's claims is a brochure.

The platform owner's and security reviewer's checklist

Which controls stay yours, which does the vendor hold, and where does each one appear in writing?

Answer every item in writing before anyone signs the order form, with Zime or with any vendor.

Shared control

The primer publishes the split [V: DevOps for RevOps]. Hold any vendor to an equivalent table.

The AI Engineers page carries a fifteen-row version of the same table (identity and access, first motion, Behavior Graph schema, models and frameworks, test scenarios, strategy mapping, environments, gate evidence, package registry, release approval, escalation path, Judgment Evals, guardrail state, 90-day plan, adoption telemetry) [V: AI Engineers]. Ask for it filled in for your deployment.

Data boundary

Release control

Identity, access, and agents

• Role-based and protected-information access controls [V: Enterprise Harness].
• Each prompt passes a policy and security check before it runs; the harness adds defenses against prompt injection [V: Enterprise Harness].
• Four guardrail states set centrally; no harness sets its own; an agent acts alone only where policy allows it without review [V: Enterprise Harness].
• Tool credentials, agent authority by motion and risk class, incident command, and final deactivation rights stay with the enterprise [V: DevOps for RevOps].
• Ask any vendor how the layer prevents an agent from committing your company to terms, then run acceptance test 6 and watch.

Observability without surveillance

The layer reports behaviors executed in live deals at four levels, broken down by rep, team, account, opportunity, stage, and Deal Motion; logins and content views do not count [V: Programmatic Adoption]. Telemetry covers inputs, actions, user response, evidence, latency, cost, and outcomes [V: DevOps for RevOps]. Whether the layer records keystrokes, time on tool, or message content outside the authorized context: UNSOURCED. Get the sentence that says it does not into the order form. If a vendor cannot write that sentence, the adoption number will not survive contact with the floor.

Exit

UNSOURCED. The pages state that customers hold a customer-specific Behavior Graph and Skill Graph, workflows, and evaluation criteria [V: Deployable Capabilities], and nothing about what happens to them on cancellation. Demand a plain statement covering packages, graph, evals, traces, and telemetry: what exports, in what format, at what cost, and what stops.

First 90 days

What should you see, and by when, so that day 90 reads as evidence rather than opinion?

The 90-day window matches Gate 2, and everything after signature arranges itself so you can read the thresholds at the end of it. The harness page describes rollout as inventory, connect, bring under the hub, observe, stay current, with no durations [V: Enterprise Harness]. The primer and the Deployable Capabilities page supply the clock.

Vendor evaluation scorecard

Which ten criteria separate a governed behavior layer from a skill library, and how heavily does each one weigh?

Ten criteria, weighted to the trade-offs that bind hardest. Score each vendor 0 to 5 on the evidence they show you, not on what they say. A vendor who scores under 3 on the first three criteria sells a skill library, whatever the pitch calls it. Apply the same scorecard to your own build.

Scoring

Multiply each score by its weight and sum. Above 4.0 means the vendor has the lifecycle. Between 3.0 and 4.0 means the vendor has parts of it; ask which parts sit on the roadmap. Under 3.0 means you are evaluating content, and Trade-off 1 already told you what to do with content.

How Zime expects to score

High on 1, 3, 4, 6, and 7; the pages publish the mechanisms and the primer publishes the tests. On 2, high on the trace and the adoption model; the telemetry capture method stays undocumented on the pages, so make Gate 1 show it. On 5, the score depends on the delivery path you choose, because encoding is the work. On 8, high on policy checks and rollback; hold and pin mechanics remain unpublished. On 9, the score depends on whether Zime brings a line-by-line comparison to the working session; Section 4 gives you the lines to demand. On 10, Zime has published nothing on exit; score it on what the order form says, not the pitch. Ask Zime to score itself on this card in front of you, with evidence, before you sign.

Questions engineers ask

Which question does each stage of the evaluation turn on?

Nine questions, each resolving one or two of the trade-offs in Section 3. Each answer opens with the one-sentence version.

We already built agents and a skill library. What does Zime add that we have not got?

Zime adds the lifecycle around your skills: packaging, Judgment Evals in your environment, a gate before promotion, versioned propagation, authority bound to the package, and telemetry that counts behaviors executed rather than logins [V: Workbench; AI Engineers; Programmatic Adoption].

Your agents, connectors, models, and data stay in place; the layer connects to them through MCP and delivers into the surfaces reps already use [V: AI Engineers; Enterprise Harness]. The difference shows up at the point where a skill library stalls: the second quarter, when the strategy moved and the skills did not, and nobody can say which version of which prompt produced last Tuesday's recommendation. Check where your build sits on Section 4's eleven waypoints. Past waypoint 8, with regression, outcome-joined telemetry, and package-level authority, keep it and run the scorecard on it quarterly.

• Package format with seven published parts
• Judgment Evals run in your environment
• Gate between evaluate and promote
• Four guardrail states, set centrally
• Adoption at four levels, logins excluded
• Trace to package version, strategy, approver

What you keep carries your judgment; what you add keeps it current and bounded. (Trade-offs 1, 4.)

Do we have to replace our models, frameworks, or agent platform?

No; Zime runs above your models, frameworks, and controls and connects to customer-built agents through MCP [V: AI Engineers; Enterprise Harness].

Model and framework selection stays with the enterprise on the shared control table [V: DevOps for RevOps]. The harness selects, routes, and substitutes models by task, sensitivity, quality, and cost, and compares cost against quality before any model change reaches promotion [V: Enterprise Harness; Workbench]. Acceptance test 4 makes the claim testable: the same package must run on your chosen model and runtime with contract, evaluations, authority, and telemetry intact. No page names specific supported models, so put the ones you run in the working session and ask for the eval delta.

• Models, frameworks, agents, connectors, data: yours
• MCP connection, permissions preserved
• Routing by task, sensitivity, quality, cost
• Delivery in CRM, Slack, Teams
• Private Deployment on your hardware

The layer adds judgment to the stack you built rather than asking for a new one. (Trade-offs 4, 8.)

What exactly is in a capability package, and what is missing from it?

A package carries a behavior or skill definition, its link to the supported strategy, prompts and structured context, workflow and integration configuration, conditions and exceptions with evidence, evaluation and regression routines, and metadata for ownership, release, version, and freshness [V: Deployable Capabilities].

Zime's primer specifies eleven parts for a Governed Deal Motion Package [V: DevOps for RevOps]. Four of the eleven have no named home in the seven: trigger, authority, telemetry, and rollback. That does not mean the product lacks them; the harness page documents guardrail states, tracing, and rollback at the platform level [V: Enterprise Harness; Workbench]. It means you should ask where they live, because a package that carries its own authority and rollback behaves differently under incident than one that borrows them from a central table.

• Seven parts published for the shipped package
• Eleven parts specified in the primer
• Ask where trigger lives
• Ask where authority lives
• Ask where telemetry lives
• Ask where rollback lives

Open one package in the working session and have Zime point to all eleven. (Trade-offs 1, 7.)

How does Zime keep an agent from committing us to terms it should not?

Central policy assigns each agent one of four guardrail states, Recommend, Act, Escalate, or Request approval, and no harness sets its own [V: Enterprise Harness].

Authority attaches to the package, not to the agent, and a three-level ladder (Copilot, Semi-autonomous, Autonomous) with evidence gates between levels decides how far a motion may go [V: DevOps for RevOps]. Each prompt passes a policy and security check before it runs, with defenses against prompt injection [V: Enterprise Harness]. In live deals, Zime guides and the person acts [V: Enterprise Harness]. Agent authority by motion and risk class, tool credentials, and final deactivation rights stay with the enterprise [V: DevOps for RevOps]. Run acceptance test 6 before you believe any of it: promote one package, simulate a threshold breach, and watch authority fall.

• Four guardrail states, set centrally
• Authority on the package, not the agent
• Evidence gates between autonomy levels
• Policy check on every prompt
• Deactivation rights stay with you

Permission becomes a property of the motion you can read, test, and reduce. (Trade-offs 7, 12.)

What do the evals test, and where do they run?

Judgment Evals test whether encoded, company-specific judgment guides correct execution in real deal situations, and they run in your environment [V: Workbench].

They cover complex-deal conditions and exception cases, and regression tests span skill, model, and context changes [V: Workbench]. Rot detection flags stale or degraded knowledge [V: Workbench]. The Workbench page shows the shape of a result: 46 of 48 passed, 2 failed on a pricing exception, 1 regression on competitor entry, cost against quality compared across two models, verdict "Do not promote yet," promotion blocked [V: Workbench]. The ground-truth scenario set sits on the shared control table as something you and Zime set together [V: DevOps for RevOps], which means the scenarios that matter to your motion get written by people who know it.

• Run in the customer's environment
• Complex deals and exception cases
• Regression on skill, model, context
• Rot detection on stale knowledge
• Gate before promotion
• Scenarios co-authored

An eval you cannot read in your own environment proves nothing about your deals. (Trade-offs 6, 1.)

How do we see what each agent costs, and can we route by cost?

The harness shows cost across inference endpoints, LLMs, and MCP calls as it accrues, attributed by team, workflow, initiative, agent, or user [V: Enterprise Harness].

Model selection, routing, and substitution run by task, sensitivity, quality, and cost, and sensitive tasks route to the models you approve [V: Enterprise Harness]. Workbench tracks cost by user, team, agent, environment, initiative, and customer deployment, and compares cost and quality before any model change promotes [V: Workbench]. Operating cost appears among the Gate 2 thresholds you set before the proof starts [V: DevOps for RevOps]. For the engineer who reconstructs agent cost from invoices, this answers the CFO's question at the level the CFO asks it.

• Cost across endpoints, LLMs, MCP calls
• Attributed by team, workflow, agent, user
• Routing by task, sensitivity, quality, cost
• Sensitive tasks to approved models
• Cost in the Gate 2 thresholds

Cost stops being a monthly surprise and becomes a per-recommendation number you can route against. (Trade-offs 8, 9.)

What does a Proof of Value prove, and how long does it take?

A Proof of Value runs one bounded revenue priority on your live pipeline against a baseline set before deployment and ends, in about three weeks, with a go, revise, or stop recommendation [V: Deployable Capabilities].

The primer formalizes it as Gate 1 at 21 days, with phases of define and connect, evaluate, integrate and approve, deploy and prove, and named exit criteria including a tested exception and rollback path [V: DevOps for RevOps]. Gate 2 at 90 days reads adoption, behavior, and movement against thresholds you set before the proof starts [V: DevOps for RevOps]. Zime targets substantial value by day 90 and makes no revenue promise [V: AI Engineers]. The eleven acceptance tests in Section 6 run inside the gates.

• One priority, your pipeline, your baseline
• About three weeks to go, revise, or stop
• Gate 1 exit criteria, observable
• Gate 2 thresholds set in advance
• No revenue guarantee

The proof produces the evidence; you make the decision. (Trade-off 11.)

What do we control, and what does Zime control?

The enterprise holds identity and data permissions, production environments, security and legal approval, model and framework selection, release approval, tool credentials, agent authority by motion and risk class, incident command, and final deactivation rights [V: DevOps for RevOps].

Zime holds the Behavior Graph schema and lifecycle, strategy-to-behavior mapping, connector behavior within authorized scope, package versioning, behavioral evaluations, its MCP, skill, and agent interfaces, behavioral and adoption telemetry, and the exception, rollback, and retirement mechanisms [V: DevOps for RevOps]. Both set the first motion, the ground-truth scenarios, gate evidence, the escalation path, the autonomy ladder, and the measurement plans [V: DevOps for RevOps]. Private Deployment runs the layer on hardware you control [V: Enterprise Harness]. What leaves your environment, and what Zime learns from it, appears on no page; get it into the order form.

• Identity, environments, release approval: yours
• Model and framework selection: yours
• Deactivation rights: yours
• Schema, versioning, evals, telemetry: Zime
• First motion and scenarios: together

Control stays with the roles that carry the risk, and the table says so in writing. (Trade-off 12.)

What do we keep if we cancel?

The pages say customers hold a customer-specific Behavior Graph and Skill Graph, workflows, and evaluation criteria [V: Deployable Capabilities], and say nothing about cancellation; the exit terms remain UNSOURCED.

The pages document rollback inside the subscription: one-click rollback to a prior approved version with a recovery owner [V: Workbench; DevOps for RevOps]. They do not document exit from the subscription. The GISTICS responsibility matrix names the lock-in risks to price: vendor-specific domain representation, incomplete evidence export, and exit cost [M]. Ask for a written statement covering packages, graph, evals, traces, and telemetry: what exports, in what format, at what cost, and what stops. A vendor's answer to this question in the first meeting tells you more than the demo.

• Graph, skills, workflows, evals: stated as yours
• Export format: unpublished
• Export cost: unpublished
• What stops on cancellation: unpublished
• Get it in the order form

The renewal decision should rest on evidence, not on how expensive leaving would be. (Trade-off 13.)

Glossary

One definition per term, held constant across this guide and drawn from the five pages.

Zime wrote this guide. Its four outcome figures appear as Zime-reported, the label its own primer gives them. Pricing, hold and pin mechanics, the telemetry boundary, and exit terms appear on no page and carry UNSOURCED above. Everything else remains yours to test on your own pipeline, with the eleven acceptance tests as the instrument.

Sources

This guide follows five zime.ai pages, all read on 26 October 2026. Tags in the text such as [V: Workbench] refer to these pages.

A note on terms. The guide uses Zime's current page vocabulary throughout.

About this guide

Where to go next