April 2026 - R&D Journal: Knowledge Freshness and Post-Conversion Intelligence¶
Context¶
April extended March's routing work into knowledge freshness and downstream sales intelligence. The research question shifted from "can Rose route correctly?" to "can Rose keep knowledge current and convert conversations into structured buyer context without slowing the chat path?"
The month advances all four validated 2026 R&D projects: the Compounding Context Engine for Company, Industry, and Buyer Intelligence (keeping retrieval knowledge fresh and ingesting scraped content), Synthesized Knowledge Publishing for Generative-Engine Discoverability (which is born this month as an internal design and pipeline), Adaptive Multi-Tenant Conversation Orchestration (collecting buyer context after a conversion without blocking it, and hardening guardrails), and Closed-Loop Agent Evaluation and Optimization (making conversion behavior observable enough for later experiments). Customer-facing releases such as the FAQ editor, in-chat booking fields, Calendly decoration, and HubSpot improvements are kept separate from the underlying R&D below.
Compounding Context Engine for Company, Industry, and Buyer Intelligence¶
This project covers the knowledge that flows into the agent at answer time. April's work on it was about keeping that inbound knowledge fresh and trustworthy as clients edit it.
Project and lock¶
Client-edited question-and-answer knowledge can improve answer grounding, but it can also degrade retrieval if entries are malformed, stale, duplicated, or synced inconsistently. The lock in April was not building an editor — create-read-update-delete is a solved problem — but the safe transformation of curated rows into retrieval-ready knowledge: validating them, keeping them current, and getting them into the retrieval index without letting a bad edit quietly poison answers. A second face of the lock is directional: this curated chat knowledge must never be confused with the marketing content the platform generates for publishing, because the two are stored in look-alike places and serve opposite consumers. March had surfaced repeated answer-quality failures patched one skill at a time; April tested whether some of that fragility could be removed by moving stable facts into structured, validated, synced knowledge instead of prompt patches.
This month's work¶
The hypothesis was that a constrained knowledge editor — one that attaches topic metadata, checks the URLs entries point at, and syncs on a schedule — can improve retrieval freshness without introducing uncontrolled knowledge drift.
The work treated freshness as a pipeline rather than an editor. Curated entries pass through validation and a scheduled sync into the retrieval index, the tenant knowledge export was extended so those entries travel with the rest of a tenant's knowledge, and the document loader was hardened so that one malformed entry fails in isolation rather than taking down an ingestion run — a non-zero failure is surfaced instead of silently dropping knowledge. Topic metadata was added so a growing knowledge base stays navigable and maintainable at scale, and the reranking model used to order retrieved passages was upgraded. The same project also widened how knowledge gets in and how it is matched: a website-scraping path was added so a client's existing pages can be turned into retrieval knowledge rather than re-authored by hand, and a separate query-rewriting route was introduced so a visitor's raw question is reformulated before retrieval, which is the query-expansion lever for finding passages the literal wording would miss.
Results, proof, and next step¶
The first learning is that knowledge freshness needs a pipeline, not just an editor: the sync jobs, export paths, URL checks, and failure isolation are the research substrate, because they are what keep a live retrieval index from drifting as clients edit. The second is that topic metadata is what makes retrieval knowledge maintainable as it grows. The boundary learning is that curated chat knowledge and generated publishing content must stay in separate stores, since April's editor concerns retrieval knowledge only. The remaining uncertainty is that April produced no measured answer-quality lift from the ingestion pipeline; demonstrating one requires evaluation coverage and production review, which the month did not run.
The evidence is the implementation history of the knowledge ingestion, scheduled sync, export, loader failure-isolation, website-scraping, and query-rewriting work. In the customer changelog, the same period shows the FAQ knowledge base, topic filtering, scheduled ten-minute sync, and the upgraded search model becoming visible — product surfaces over the retained pipeline beneath them.
Next step: connect knowledge ingestion to evaluation so freshness translates into a measured grounding gain rather than an assumed one, while preserving the chat-versus-publishing boundary.
Synthesized Knowledge Publishing for Generative-Engine Discoverability¶
This project is born in April, internally. It is the outbound twin of the knowledge-freshness work above: where that pipeline feeds knowledge into the agent, this one synthesizes knowledge to publish it outward for search and generative engines. April produced the design and the first internal pipeline, not customer-visible pages — so it appears here as a genesis with no published output yet, which is exactly why it must be recorded as its own line rather than folded into the inbound work.
Project and lock¶
The platform needs to turn what it knows about a client into answer-grade pages that a search or generative engine will discover and cite. The lock, recognized at design time, is that this is not the same problem as chat knowledge even though it starts from the same material: a published page's value depends on being generated at answer quality, reviewed before it goes live, hosted somewhere crawlable, and — critically — kept out of the agent's own retrieval path, because marketing content written to rank must never leak back into the answers Rose gives. Naming this as a separate concern, rather than a feature of the FAQ pipeline, was itself the month's main result on this project.
This month's work¶
The hypothesis was that generated publishing needs its own pipeline and its own review surface, separate from chat-knowledge ingestion, before any page is published.
The work began with a design document and product requirements for a content agent dedicated to generating publishable answer content, and then built the first internal version of that pipeline together with a review interface where generated FAQ content can be inspected before it is approved. This is deliberately a human-gated, pre-publication step: the month built the means to synthesize and review, not yet the hosting, canonicalization, or indexing that later months add.
Results, proof, and next step¶
The defining learning is the one that justified splitting the project out: generated publishing content and chat-retrieval knowledge look like the same artifact and must be handled by different pipelines with different consumers, and the review-before-publish gate is part of the design, not an afterthought. The remaining uncertainty is total: April built a design and an internal pipeline with a review UI but published nothing, hosted nothing, and measured no discoverability — there is no ranking, crawl, or citation signal yet, because there are no live pages. The honest status is genesis: the project exists, with a pipeline and a review surface, and no outcome.
The evidence is the content-agent design document and product requirements, and the implementation history of the internal content-agent pipeline and FAQ review interface. There is no customer changelog surface this month, because the work is internal and pre-publication.
Next step: add hosting, canonicalization, and indexing so a reviewed page can actually be published and its discoverability measured.
Adaptive Multi-Tenant Conversation Orchestration¶
April opened a new conversation contract: collecting buyer context after a conversion rather than gating it before one. This is the precursor to the soft-qualification and attribution work that continues in later months.
Project and lock¶
Post-conversion qualification introduces a sequencing problem. The agent must react after a conversion event, ask follow-up questions without blocking or undoing the primary conversion, persist the answers, and deliver structured context to downstream sales systems — all without making the visitor wait on a synchronous write to an external CRM. The lock is holding that ordering deterministically: the conversion must complete first and unconditionally, the qualification phase must be bounded so it does not nag, and the CRM delivery must be decoupled so a slow external system never blocks the conversation. March's routing work had made the conversation reliable enough to build this downstream phase on; April tested whether the phase could be added without compromising the conversion it depends on.
This month's work¶
The hypothesis was that post-conversion qualification can collect useful buyer context if it is triggered only after conversion, bounded by an explicit progress state, and decoupled from synchronous CRM writes.
The work built the post-conversion qualification flow and persisted its answers, then delivered them to the sales system as structured context — a sales memo, bootstrapped contact properties, and notes pushed asynchronously over webhooks rather than as a raw transcript. A significant part of the month went into attribution, because crediting the conversion correctly turned out not to be a single mechanism: native form-submit events are unreliable on modern and embedded forms, so the work added multiple detection strategies, provider-aware tracking, and cross-subdomain attribution, and restored a batched delivery queue so navigation-time events are not lost when the page unloads.
Two further conversation contracts were hardened in the same month. The booking flow gained a deterministic pause-and-exit behavior: a visitor can digress with a real product question mid-booking and be answered and softly re-prompted, or decline outright and have the flow exit cleanly, instead of being trapped in a "share your email" loop. And the agent's guardrails were strengthened against adversarial framing — requests disguised as poems, code, hypotheticals, or persona instructions are now refused — alongside query-size guards, an abuse gate, and session-concurrency limits that bound token-abuse. Both are the same kind of work as the qualification contract: moving a rule the model would otherwise improvise into a deterministic boundary.
Results, proof, and next step¶
The first learning is that qualification should not always be pre-conversion: collecting it after conversion preserves the primary conversion path and creates a separate, lower-risk buyer-context phase. The second is that CRM delivery must be asynchronous and structured — a raw transcript carries little value, and a synchronous write would couple the conversation to an external system's latency. The negative learning is that attribution cannot rely on native submit events; modern forms and embedded providers require several strategies running together.
The honest measure of where this stood is adoption: the post-conversion flow shipped late in April and was barely exercised. Across the month it recorded on the order of forty-five starts and twenty completions, but from around a dozen distinct visitors, fewer than five of them completing it — a sample from which no completion rate or downstream sales value can be inferred. The contracts are in place; the effect is unmeasured, and the month records that rather than reading a trend into single-digit visitor counts.
The evidence is the implementation history of the post-conversion qualification flow, the asynchronous structured CRM delivery, the multi-strategy attribution and event-delivery work, the booking pause-and-exit contract, and the adversarial, abuse, and injection guardrails. In the customer changelog, the same period shows post-conversion qualification, in-chat booking pause-and-exit, and the stronger adversarial protection becoming visible — product surfaces over the deterministic contracts beneath them.
Next step: let the post-conversion flow accumulate enough volume to measure completion rate and downstream value, and carry the attribution strategies into the broader call-to-action work.
Closed-Loop Agent Evaluation and Optimization¶
April's contribution here was making conversion behavior observable enough that a later experiment could read it — the first step toward the measurement architecture built in May.
Project and lock¶
To run a controlled experiment on conversion, the conversion itself must first be observable in a way an experiment can trust. The lock is that a conversion has several possible origins — chat, a client form, a booking provider, a content recommendation — and attributing it consistently requires a deterministic rule rather than per-surface guesses. Until that rule exists, any measured "lift" is an artifact of inconsistent counting.
This month's work¶
The hypothesis was that a deterministic conversion-attribution rule, plus observability over how recommendations and form events are delivered, would turn raw tracking into a signal an experiment could later read.
The work added a conversion-attribution decision tree that resolves which origin a conversion is credited to, observability over content-recommendation behavior and over whether form-tracking events are actually delivered, and re-initialization hardening so the tracking survives the page lifecycle. It also continued unifying the metric definitions begun in March: the conversion-rate denominator was corrected, and the dashboard began reporting booking rate both with and without Rose side by side — a with-versus-without comparison that is the conceptual seed of the held-back-control experiment. The integrity of the measurement layer was hardened too, by revoking direct API access to the materialized views so the analytics tables cannot be read or mutated outside the intended path. Toward the experiment itself, the first controlled test was specified and created in the experiment platform on 21 April — a held-back control in which the widget is not shown against a treatment in which it is, with form conversion as the primary metric.
Results, proof, and next step¶
The learning is that most of this is supporting infrastructure: raw tracking wiring is not itself research, and becomes R&D-relevant only where it resolves the attribution uncertainty that otherwise corrupts measurement — the decision tree, the denominator definition, and the with-versus-without comparison are the parts that matter, not the charts. The concrete experiment-linked fact for April is a null: the first controlled experiment was designed and created on 21 April but left in draft, not launched, so there is no cohort and no result. The eval side grew too — several per-client evaluation datasets were created during onboarding, and some were run during April — but those runs carried no item-level scores, so there is no measured eval number to report for the month either. April built the attribution rule and the experiment design the loop needs; it did not yet run them.
The evidence is the implementation history of the conversion-attribution decision tree, the denominator and with-versus-without metric changes, the materialized-view access lockdown, and the draft experiment record created on 21 April. In the customer changelog, the weighted and corrected conversion metrics and the per-client tracking columns are the visible surface; the retained work is the definition and attribution logic beneath them.
Next step: launch the designed widget-display experiment once the attribution rule is trusted, and fold the per-surface observability into the layered measurement substrate.
Non-R&D / Productization Context¶
Not retained as R&D:
- CSV export for conversations.
- Backoffice table columns, badges, and UI improvements.
- Client-specific skill fixes and onboarding.
- Dependency upgrades and CI/tooling changes.
- Changelog and documentation updates.
- Standard CRM integration UI polish, except the asynchronous structured-delivery work named above.
Research Outcome¶
April's key result was that several concerns that look like one "knowledge and conversion" mass are in fact separate locks with separate homes. Keeping client-edited knowledge fresh and safe for retrieval, and widening how it is ingested and matched, is inbound-context work. Synthesizing knowledge to publish it outward for engines is a different, outbound concern — which is why the Synthesized Knowledge Publishing project is split out and born this month as an internal design and pipeline. Collecting buyer context after a conversion, and bounding booking and guardrail behavior, is a set of deterministic conversation contracts. And making conversion countable with a single definition and a trustworthy attribution rule is measurement work. The editor, widget, CRM, and analytics surfaces are product; the retained R&D is the transformation of changing client data into retrieval knowledge, the genesis of a separate publishing pipeline, the deterministic contracts for qualification, booking, and guardrails, and the attribution-and-definition logic that makes conversion measurable. What April did not yet have was any measured effect: the post-conversion flow ran at near-zero volume (about forty-five starts and twenty completions from around a dozen distinct visitors, fewer than five completing), the answer-quality lift was not evaluated, the publishing pipeline published nothing, and the first controlled experiment was created but left in draft. April built the contracts and the instruments; the readings come later.