Quality and performance
Quality shows how much of what you designed actually reaches the agent; Performance shows how long assembly takes. Both live on the Observe tab, with the same filters as Usage — Domain, Library, Artifact, Surface, Level, Format.
The two percentages measure entity loads. ContextWorks serves a brief, a skill or an Info whole, so there are no fields to count: filter Library to any of those three and both percentages go blank. Assembly time reads 0 for those three as well, because ContextWorks doesn’t time them. Entity loads and catalog reads report their failures to Issues.
How it works
Every load runs a three-stage funnel:
Two percentages separate the stages, so you know whether to fix a permission set or a data problem. Both are load-weighted daily averages: an entity loaded 100 times counts 100 times. Multiply them and you get the share of designed fields that reached the agent with a value in them.
FLS coverage %
Of the fields the entity asks for, the share the caller’s permissions allow (accessible ÷ requested). ContextWorks drops the rest silently: nothing in the payload says a field is missing, so the agent answers from thinner context. 100% means every caller received exactly what you designed.
When it dips, Issues names the stripped fields under fls_strip. Fix the permission set, or remove the field from the entity.
TIP
Low FLS coverage usually explains “the agent doesn’t know about X” when preview shows X fine. Preview runs as you; the load ran as the caller.
Data completeness %
Of the fields the caller could see, the share that actually held a value (populated ÷ accessible). Low completeness means the entity leans on fields people rarely fill in. Get them populated, or take them out of the entity.
Reading them together
| FLS | Completeness | Diagnosis |
|---|---|---|
| High | High | Working as designed |
| Low | High | A permissions problem — the audience can’t see what you built |
| High | Low | A data problem, or over-curation — fields are empty |
| Low | Low | Both. Start with permissions — completeness counts only the fields that survived |
ContextWorks records coverage field by field as well, on the Field Metric object. No Observe page charts it, so report on that object when you need to see which field drags the number down.
The page carries two charts. Completeness & FLS coverage % plots both percentages as lines on a shared 0–100 axis: how grounded payloads are. Errors & issues by day plots counts as columns: what is going wrong. When the lines dip and the columns rise on the same days, start with Issues, which names the cause.
Performance
Observe → Performance shows assembly time, with the same filters and shape. Cost is dominated by queries:
| Part | Cost |
|---|---|
| Fields | One query for the record |
| Metrics | Batched — metrics over the same related object, with the same filter, share one aggregate query |
| Formulas | None — evaluated in memory |
| Each related list | Rides the record’s own query as a subquery. A second list on the same relationship needs a query of its own |
| Each reference | A second assembly of the referenced record — its own query, plus whatever that entity’s own metrics and lists cost |
| Each enrichment | Runs its own code — typically a query per record |
Ten metrics over the same related list cost about what one costs. Related lists add rows rather than queries, and those rows are the largest item in most payloads. For the same information, a metric is far cheaper in tokens.
If one entity is slow, count its enrichments first — three or four Apex providers is usually the whole answer. Raising their minimum level to detailed takes them off leaner payloads.
Both pages take a timeframe and export to CSV, so you can track a curation change over weeks or report outside the Studio.