Meeting Summary · 30 April 2026
PLP Engagement
A grounded-inference assistant for the Practice Licence Processor function: scope, architecture, engagement and next steps from our call.
What we're building
A grounded-inference assistant for the Practice Licence Processor function across three operational surfaces: PL processing, member email triage, and case management. Humans in the loop on every outbound. The system is shaped to ICB's specific use case, and designed to outlive the engagement, continuing to support the team after the absent staff return.
- Three workstreams aligned on the call: PL processing, email triage, and case management and complaints.
- Engagement: May to July 2026, three months at £3,750 per month, conditional on Ami's and Julius's sign-off.
- Three vendor conversations to set up: James (Sodalis), Kyle (replacement architect), and Julius (IT and approvals).
01 · Scope and architecture
Three Workstreams
The meeting aligned on three workstreams, rather than the two on the table going in.
Practice Licence processing01
The seven stages in Agatha's draft SOP. Mostly mechanical document checking against the rubric.
Volume around one application every other day. The new online application form via James replaces the email-attached-PDF intake when it goes live.
~1 application every other day
Email triage02
High-volume member queries currently bouncing between Professional Standards and Member Services with inconsistent answers.
The build target is triage plus a suggested response plus a "you need to check this and this" prompt list, surfaced to the PLP for human decision.
Highest volume surface
Case management & complaints03
Around seven active complaint cases per year, currently held in unstructured SharePoint folders with no progress tracking.
ICB's highest-risk operational surface (the BBC Complaints situation Agatha raised). Brought into scope explicitly because letting it leak in implicitly during the engagement would not serve either side.
Highest-risk surface
Architectural choices that landed on the call
These were aligned in-call rather than left open.
- Web app in a browser tabSeparate from Sodalis. Tiered access: PLPs process; only senior staff change rules.
- AI suggests, humans decideWhen a PLP overrides the AI, the divergence is flagged for review by Ami or June. The AI then proposes rule-book amendments which require explicit human approval before adoption. No continuous self-learning.
- Multi-agent systemA primary agent with sub-agents for Sodalis querying and email handling, each as a tool.
- Email handling via a forwarded mailboxICB inbound forwards to a dedicated mailbox the agent reads. Avoids deep coupling to the Microsoft 365 stack. Replies surface to the PLP as click-to-clipboard text rather than direct send.
- PII redaction layerAn on-premises automation substitutes names and company names with keys before sending to frontier models, decoded on return. Keeps the build inside the legitimate-interest plus AML-supervisor-duty GDPR basis Ami articulated.
- Eval-first methodologyBuild a test set from historical applications and email queries with known-correct answers. Run evals against this test set to fine-tune the system before applying it to new applications and emails.
- Dashboard layerPer-case timeline view, colour-coded by severity. Manager dashboard reports on PLP dashboards: observability of decisions, divergences, and queue.
Architecture coordinates with Kyle's rebuild
Kyle is building a full replacement for Sodalis on Supabase, Vercel and Aikido.
Implication for the build: the assistant is not coupled to Sodalis. Instead it maintains a database that Sodalis, or its replacement, can query: the integration direction reverses. This keeps it portable across both worlds with minimal rework.
Read access from Sodalis remains the unsolved question and is the substance of Jordan's conversation with James.
02 · Engagement and next steps
Engagement
May, June & July 2026
Three-month window
£11,250
£3,750/month, paid monthly in advance
The shape of the engagement is best described as follows. Jordan is hired as a temp Practice Licence Processor for costing and procurement purposes: that framing makes the price legible to ICB's procurement habits and benchmarks cleanly against a temp at ~£45k pro-rata. In practice the engagement is email-only: Jordan will not be taking calls, and will be working on other commitments in parallel. The temp framing is the right shape for procurement; it is not a description of the working pattern.
Conditional on Ami's and Julius's sign-off on the ICB side.
Vendor conversations to set up
Introduced by Agatha, Jordan will meet separately with:
- James (Sodalis vendor). Scope what API access can be built, on what timeline, and at what cost. Browser-use over Sodalis is an acceptable fallback at the application volume if a usable API cannot ship in window.
- Kyle (Sodalis replacement). Architectural coordination so the assistant slots into his future system as cleanly as the current one.
- Julius (IT, email, approval gate). Operational sign-off on the consultancy and the dedicated forwarding mailbox.
Action items
Jordan
- Hold the three vendor conversations once Agatha makes the introductions.
- Share a tightened proposal following the vendor conversations.
- Issue SoW and first invoice.
- Commence the two-week setup window ahead of live cover, for shaping the assistant against ICB's working examples and dry-run testing.
Agatha
- Send connection emails to James, Kyle and Julius (James and Kyle done; Julius TBC).
- Confirm exact absence dates for both PLPs.
- Pass the consultancy through Julius for sign-off.
- Pull together a representative working set of past Practice Licence applications and member email queries, both straightforward decisions and tricky edge cases with the outcomes recorded, that the assistant can be shaped against. The richer this set, the better the system fits the ICB way of working from day one.
Ami
- Confirm the proposal and cost.
- Review the weekly meeting minutes for personal information before they're used to shape the assistant.