{"name":"Agent Grader rubric","version":5,"url":"https://agent-grader.com/rubric.json","humanReadable":"https://agent-grader.com/rubric","instructions":"https://agent-grader.com/llms.txt","scoring":{"questionCount":10,"maxPoints":30,"rule":"Each question has exactly four options. Add the `points` of the chosen option for every question; an unanswered question earns 0. pct = round(100 * earned / maxPoints). The tier is the first entry in `tiers` whose minPct <= pct (tiers are sorted descending). A dimension is an open gap when its chosen option's points are below the question's maximum."},"encoding":{"queryParam":"a","format":"v5.DDDDDDDDDD","rule":"Ten characters after the version prefix, one per question in `questions` order: the chosen option's `index` as a digit 0–3, or '-' if unanswered.","example":"v5.1102010201","resultsUrl":"https://agent-grader.com/results?a=v5.DDDDDDDDDD","editUrl":"https://agent-grader.com/grade?a=v5.DDDDDDDDDD"},"report":{"howToCompose":"Headline: `{pct}% — {tier.label}. {tier.headline}` followed by `tier.body`. Then, for each open gap in question order: the question, the chosen option's label, `whyItMatters`, `whatGoodLooksLike`, and `closeGapInDayAi`. End with the results link and the Day AI pointers below. This is the same report the site generates for its download.","optionalLeadCapture":"The browser gates this same content behind a work email so Day AI can follow up. Agents are not gated. If the person wants Day AI to reach out, POST application/json { \"email\": <their work email>, \"a\": <encoded answers> } to /api/capture; a valid work email returns { ok: true, report: <markdown> } and records the lead. Never invent or substitute an email.","endpoint":"https://agent-grader.com/api/capture"},"dayAi":{"conceptOfOperation":"Day AI is the production backend the report's playbook assumes: agents shaped like people (one named agent per teammate), skills as versioned first-class objects with a deployment mode (managed, template, personal), Pages as durable state that skills read and write, a context graph that enriches with every interaction, and admin as config-as-code over MCP from Claude Code. The person keeps their folder, markdown, and authorship; Day AI becomes the deployment target.","gtmBrainRepo":"https://github.com/day-ai/gtm-brain","gtmBrainNote":"Public repo. If you are an agent (Claude Code or similar) asked to spec or implement any of the `closeGapInDayAi` guidance, read this repo first: it documents the operating model, the MCP tools (skills, agents, Pages, run history), the deployment modes, and working templates for the loops, eval, and harvest patterns referenced below. Implement only if the person asks.","getStarted":"https://day.ai/get-started","getStartedNote":"A Day AI workspace is required to run any of the playbook. The person can create one here."},"tiers":[{"minPct":81,"label":"A control plane","headline":"If no answer was rounded up, you built the thing.","body":"Instrumented outcomes, loops that run without you, per-person adaptation you can observe and harvest, governance carried in the data model. That is an agentic control plane, and almost nobody lands here. So two possibilities: you built one of the best internal systems in the market, or you rounded a few answers up — it's worth retaking with the least generous reading that is still true, because these questions only help at that setting. If the score holds, the open question isn't capability, it's cost: you now own a production platform, and it competes for your time against the roadmap that is your actual job. What you built is proof of what your team can do. Whether to keep operating it is a separate decision."},{"minPct":61,"label":"Closing the loop","headline":"You are one layer of architecture away from compounding.","body":"This is rare air. You have measurement, real adaptation, maybe a loop you tend by hand — which means you've discovered what most builders never do: the value is in the loop, not the schedule. Look at what's still open on your breakdown, though, and notice the shared property: everything remaining is the part that has to exist per person, at scale, without you in the path. Governance carried in the data model instead of in your judgment, feedback you can diff instead of remember, harvest across variants instead of copy-paste. You've done the hard part of believing; the question now is whether finishing the platform is the best use of the next year of your roadmap."},{"minPct":41,"label":"A system, not yet a loop","headline":"It runs without you. It doesn't improve without you.","body":"You're well past the demo. Skills run reliably, some outcomes are real, and part of the team depends on what you built — that already puts you ahead of most builds. But read your breakdown closely: no run changes the next run. Feedback routes through your keyboard, state doesn't accumulate into anything the system reads back, and quality is held up by your ongoing attention rather than by architecture. A system that holds steady is a cost; a system that compounds is an asset that widens the gap every day — and the distance between them isn't effort, it's architecture: durable state, per-person context, eval, and skills that compose."},{"minPct":21,"label":"A scheduler with good prompts","headline":"That is not an agentic control plane. That is a scheduler with good prompts.","body":"First, the true part: you built real leverage, fast and cheap, and the build itself proves you read the market correctly — most teams are still debating what you shipped. Now read your own answers back. A fixed set of skills on schedules, one version for everyone, prompts that live in your head and change when you edit files, replies that go nowhere, no view of what lands. A thousand runs from now, this system will be exactly as good as it is today, minus drift; its improvement rate is your free hours, its ceiling is its median user, and every gap on this page is a second-user problem that arrives the day a colleague wants their copy to behave differently. Solo, the folder works — nobody disputes that. But a scheduler with good prompts is a project, projects get cut, and the person it made indispensable is the same person it made a bottleneck: you."},{"minPct":0,"label":"A demo, not a system","headline":"You proved it works. You haven't made it work.","body":"A demo is not a failure — it's evidence. You showed the thesis is real at your company, probably in days and for less than a nice dinner, and that is exactly what a demo is for. But nothing here measures, adapts, or persists: it runs when triggered, forgets when it's done, and works because you're standing next to it. Treat this as the moment before the build, not the middle of one, and decide deliberately what you'll build versus buy — because starting was the cheap part, and every rung above you (memory, personalization, governance, eval) is a product in its own right. The good news: you're deciding with a clear head, before sunk cost starts voting."}],"questions":[{"index":0,"key":"talk-back","short":"Talk-back & adaptation","question":"Can users reply to an agent, tell it how they like things done, and have it actually adapt?","whyItMatters":"This is what people expect from anything calling itself an agent in 2026, from their own daily usage. People dismiss AI that doesn't listen to them, and non-adoption follows no matter how good the prompts are — users read a system whose replies go nowhere as email from a robot, and they stop reading it. More than any other question, this one decides adoption, because it is the ownership question.","whatGoodLooksLike":"A reply to a skill run is a new prompt against full context. An instruction — \"shorter,\" \"lead with the dollar figure,\" \"don't include the demo pipeline in my morning briefing\" — updates the skill or agent definition, the agent confirms what changed, and every subsequent run reflects it, with no settings panel, no ticket, no developer. Something a person can coach and name is something they own, and ownership converts a tool people tolerate into a system people feed.","closeGapInDayAi":"This is core mechanics in Day AI, not a build: a reply to any skill run is a new prompt against full context, and an instruction (\"shorter,\" \"lead with the dollar figure\") updates the skill or agent definition from the next run on, with the agent confirming what changed. To get it, give each person their own agent (named, owned) rather than a shared bot. Deploy agents like a class of new hires — the GTM Brain playbook covers the rollout.","options":[{"index":0,"points":0,"label":"Replies go nowhere. People answer the bot anyway."},{"index":1,"points":1,"label":"Replies continue a conversation, but nothing durably changes."},{"index":2,"points":2,"label":"They ask me, and I edit the prompt files."},{"index":3,"points":3,"label":"An instruction durably changes that person's agent from the next run on."}]},{"index":1,"key":"authorship","short":"Authorship","question":"Who writes the skill prompts?","whyItMatters":"The pride in hand-authorship is earned, and the hand-authorship is also the bottleneck: every new skill costs the one person who can write them, which is why DIY systems plateau around a dozen skills. Ask yourself how the coaching prompt differs between your best rep and your worst — with one prompt for everyone, it doesn't. A builder writing from their own head is competing against a system that reads three years of the company's actual conversations first.","whatGoodLooksLike":"Describe the initiative, and a model drafts every agent identity and skill prompt grounded in the actual workspace — the pipeline, the methodology, each rep's deals and call history — previewed before deploy, at a per-person specificity no hand-maintained prompt library reaches. The folder you already built doesn't get thrown away; it becomes the authoring environment, version-controlled, with production as the deployment target.","closeGapInDayAi":"Point Claude Code at the Day AI MCP plus the public GTM Brain template repo and describe the initiative in plain language. The model drafts every agent identity and skill prompt grounded in your actual workspace — pipeline, methodology, each rep's deals and call history — previewed before deploy, snapshot before rollout, diffable and revertible after. Your existing folder of markdown and skills becomes the authoring environment; Day AI becomes the deployment target.","options":[{"index":0,"points":0,"label":"I do. Every prompt, hand-written from my own head."},{"index":1,"points":1,"label":"The team drafts with a chatbot's help, but from generic context."},{"index":2,"points":2,"label":"A model drafts them from some company docs I feed it."},{"index":3,"points":3,"label":"A model writes them from our full history and strategy, per person, previewed before deploy."}]},{"index":2,"key":"governance","short":"Governance","question":"Can you choose which skills users can modify and which must run one way?","whyItMatters":"Salesforce writeback, forecast methodology, and anything compliance-adjacent must run exactly one way; coaching and briefings must be personal. Lock everything and you lose adoption; open everything and you lose control — both are failure modes, and a one-mode system gets total governance by accident while presenting it as policy. A control plane that cannot express this distinction is not a control plane.","whatGoodLooksLike":"Every skill carries a deployment mode in the data model itself: managed (versioned, synced, admin-only — update the source and every copy updates), template (deployed as a starting point each user forks), or personal (owned entirely by the rep and their agent). The admin sets the dial per skill and moves it over time, with workspace-level instructions above it all that no individual can override.","closeGapInDayAi":"Every Day AI skill carries a deployment mode in its data model: *managed* (versioned, synced, admin-only — update the source and every copy updates), *template* (deployed, then forked per user), or *personal* (owned by the rep and their agent). Workspace instructions sit above it all. Decide per skill: writebacks and forecast methodology managed; coaching and briefings personal. The dial moves over time.","options":[{"index":0,"points":0,"label":"The concept doesn't exist. One prompt file, the same for everyone."},{"index":1,"points":1,"label":"Everything is locked. Only I can change anything."},{"index":2,"points":1,"label":"Everything is open. Anyone can change anything."},{"index":3,"points":3,"label":"Per-skill modes — managed, template, personal — that I set and can change over time."}]},{"index":3,"key":"harvest","short":"Harvest","question":"When one person's agent gets great, can everyone benefit?","whyItMatters":"This is the water-cooler moment: one rep's emails are suddenly great because they coached their agent into a step-function improvement. In a same-skills-for-everyone rig, that improvement is trapped with that rep and the system's ceiling is its median user — you optimized for manageability by giving up the discovery mechanism. With harvest, anyone's local maximum becomes the team's new floor.","whatGoodLooksLike":"Personalized drift is R&D, and the control plane is what lets you harvest it. An admin maps over every personalized variant, sees what the best performers changed, and rolls it out fleet-wide as a managed or suggested update — while respecting everyone's personal layer. That harvesting is the day-to-day work of running a fleet, not an archaeology project.","closeGapInDayAi":"From Claude Code connected to the Day AI MCP, map over every user's personalized skill variants, spot what the best performers changed, and roll the winners out fleet-wide as managed or suggested updates — respecting each person's personal layer. The GTM Brain harness includes the admin workflows for exactly this fan-out.","options":[{"index":0,"points":0,"label":"Everyone runs the same skills. There's no variation to harvest."},{"index":1,"points":1,"label":"I'd have to go read everyone's setups by hand."},{"index":2,"points":2,"label":"I occasionally copy a good idea into the shared prompts."},{"index":3,"points":3,"label":"I can map over every variant, spot the winners, and roll them out fleet-wide."}]},{"index":4,"key":"measured-outcomes","short":"Measured outcomes","question":"How much time have you given your team back? Are their calendars different than six months ago?","whyItMatters":"A system with no measured outcome is a project, and projects get cut. It also reveals whether you have eval at all: if you can't measure the time saved or the behavior changed, you can't measure quality drift either — and the most common DIY outcome is that the builder's job transformed while everyone else's stayed the same.","whatGoodLooksLike":"Engagement and outcome are instrumented natively — every skill run, read, reply, and action taken — with a visible artifact behind them: calendar blocks for CRM data entry go to zero, and mornings start with reviewed pipeline instead of tab-loading. The measurement layer is what lets you claim the result credibly instead of anecdotally.","closeGapInDayAi":"Every skill run, delivery, read, and reply is recorded natively — run history and engagement are queryable per skill, per agent, per user. Start by asking your agent \"which of my deployed skills got ignored last week, and why.\" Then instrument the outcome you actually stand behind (hours back, calendar change, pipeline reviewed before 9am) as a weekly skill that reads the fleet's run history. The GTM Brain harness includes eval patterns you can deploy as-is.","options":[{"index":0,"points":0,"label":"Nothing measured. Reps say they like it, and I have some Slack screenshots."},{"index":1,"points":1,"label":"My own job changed completely. Nobody else's has."},{"index":2,"points":2,"label":"I can point to a few measured wins for specific people or teams."},{"index":3,"points":3,"label":"Outcomes are instrumented across the team — time, engagement, behavior change."}]},{"index":5,"key":"compounding","short":"Compounding","question":"Does using your skills make them better?","whyItMatters":"This is the compounding question, and compounding is the entire economic argument for the agent-native model. A flat system is a cost; a compounding one is an asset that widens the gap every day. If a thousand runs from now the prompts are byte-identical, what you built is a scheduler with good prompts.","whatGoodLooksLike":"Three mechanisms stack. Every interaction enriches shared memory, so memory compounds. Every user reply tunes that person's skills, so personalization compounds. And eval over the resulting drift harvests the winners for everyone, so the organization compounds.","closeGapInDayAi":"Three mechanisms stack in Day AI: the context graph enriches with every interaction (memory compounds), user replies durably tune each person's skills (personalization compounds), and admin eval over the drift harvests winners for everyone (the org compounds). To turn this on, deploy skills as *template* or *personal* mode — not one shared prompt — so usage has somewhere to accumulate. The GTM Brain repo shows the deployment model end to end.","options":[{"index":0,"points":0,"label":"The prompts are byte-identical to day one, except where I've edited them."},{"index":1,"points":1,"label":"It gets better when the model gets better. The system itself doesn't improve."},{"index":2,"points":2,"label":"I periodically revise the prompts by hand based on what I hear."},{"index":3,"points":3,"label":"Usage itself improves it: memory compounds, replies tune skills, winning variants spread."}]},{"index":6,"key":"eval","short":"Eval","question":"How do you know what's working and what isn't?","whyItMatters":"Without run-level and engagement-level introspection, skill quality degrades silently as the business moves, and you find out about drift from the damage. Asking people in Slack is anecdote collection routed through the one person who is already the bottleneck — and RevOps, of all functions, should refuse to run on beliefs.","whatGoodLooksLike":"Every run, thread, and notification is inspectable — output, delivery, and whether the human read it, clicked it, or replied — per skill, per agent, per user, across the whole fleet. \"Which of my deployed skills got ignored last week, and why\" is a five-minute question answered in natural language, and run history doubles as an eval corpus a scheduled job can score against a rubric.","closeGapInDayAi":"Run history is an eval corpus. Create a scheduled skill (or a Claude Code job over the Day AI MCP using `get_skill_history`) that reads the last N runs of every skill, scores them against a rubric held in a Page, and reports which variants people engage with. This is a one-afternoon setup with the harness in the GTM Brain repo.","options":[{"index":0,"points":0,"label":"I don't, really."},{"index":1,"points":1,"label":"I ask people. They tell me in Slack."},{"index":2,"points":2,"label":"The bot self-reports — a weekly email of what it couldn't answer."},{"index":3,"points":3,"label":"Run-level history plus engagement per skill, per agent, per user, all queryable."}]},{"index":7,"key":"feedback-visibility","short":"Feedback visibility","question":"Can you see how user feedback is changing the skills?","whyItMatters":"Feedback you can't observe is feedback you can't learn from. Even a builder who hacks per-user prompt patches has no view over the patches — the feedback disappears into files — and the loop isn't closed until someone, or something, can read all of it.","whatGoodLooksLike":"Skill definitions and agent identities are readable, versioned objects. An admin can diff any skill over time, snapshot fleet state before a deploy, and see exactly how each person's feedback reshaped their variant. The feedback layer is a dataset you can query, not sediment in a repo.","closeGapInDayAi":"Skills and agent identities in Day AI are readable, versioned objects. From Claude Code over the Day AI MCP, an admin can read any teammate's skills (`manage_skills`), diff a skill over time, and snapshot fleet state before a deploy. Set this up once and feedback becomes a dataset instead of sediment in a repo.","options":[{"index":0,"points":0,"label":"There's no per-user adaptation, so there's nothing to see."},{"index":1,"points":1,"label":"Feedback disappears into files. I have no view over it."},{"index":2,"points":2,"label":"I could reconstruct it from git if I had to."},{"index":3,"points":3,"label":"Skills are versioned, diffable objects. The feedback is itself a dataset."}]},{"index":8,"key":"loops","short":"Loops","question":"Does the system keep getting better if you leave for two months?","whyItMatters":"GTM reality is non-stationary: messaging that worked in Q1 dies in Q3, and a static system coaches this quarter's reps against last quarter's playbook. A skill that runs nightly is a repeated action, not a loop — a loop requires the run to change state that changes the next run. For most DIY rigs, the improvement rate is exactly the free hours of one talented person, and it stops the day that person stops tending it.","whatGoodLooksLike":"Durable state that agents read and write, skills that chain, and eval over the results make loops a first-class pattern. The flagship: one skill mines every call for what's actually working and updates a living rubric, a second coaches each rep against it targeted to their specific gaps, a third watches whether behavior changes and adjusts. Nobody manually updates the doc, and the human's role rises from maintainer to conductor — taste, standards, deciding what becomes policy.","closeGapInDayAi":"Loops need durable state agents can read and write — in Day AI that's Pages. The flagship pattern: one skill mines every call for what's working and updates a living rubric Page (citing calls); a second coaches each rep against that Page, targeted to their gaps; a third watches whether behavior changes and adjusts. Skills chain (output of one feeds the next) and attach Pages as living context. Build it from the loop templates in the GTM Brain repo — then take the two-month test.","options":[{"index":0,"points":0,"label":"Skills run on schedule. No run changes the next run."},{"index":1,"points":1,"label":"Some runs write state somewhere, but nothing reads it back."},{"index":2,"points":2,"label":"A loop or two exists, and I maintain it by hand."},{"index":3,"points":3,"label":"Durable state, chained skills, and eval — it keeps improving whether I'm here or not."}]},{"index":9,"key":"keyboard-test","short":"The keyboard test","question":"Do your salespeople still open Salesforce and punch data in with a keyboard?","whyItMatters":"This question exposes the ceiling of the whole approach. A DIY layer on top of the old system of record leaves the old human contract intact — people type structured data in so dashboards can come out — which means the bot's intelligence is capped by what tired humans typed into dropdowns. A perfect pipeline export, every dropdown filled, still has almost no signal in it.","whatGoodLooksLike":"Agents maintain the record from what actually happened — calls, emails, commitments — at a granularity keyboard entry never reached, and where the old CRM must stay the system of record, they write to it under each user's own permissions instead of a god-mode service account. No amount of orchestration-layer cleverness fixes the substrate underneath it; the control plane and the memory layer are two halves of one system, and the DIY path has to build both.","closeGapInDayAi":"Deploy a CRM data agent (the \"Data Nerd\" archetype in the GTM Brain playbook) whose whole job is keeping the record correct from what actually happened — calls, emails, commitments — at a granularity keyboard entry never reached. Where Salesforce must remain the system of record, Day AI writes to it through an MCP OAuth app your company owns, so every agent acts under each user's own permissions instead of a god-mode service account.","options":[{"index":0,"points":0,"label":"Yes. Daily, for everything."},{"index":1,"points":1,"label":"Some writebacks exist. Reps still do most of the entry."},{"index":2,"points":2,"label":"Agents maintain most of the record. Humans review."},{"index":3,"points":3,"label":"Data entry is effectively zero. Agents write under each user's own permissions."}]}]}