Work · AI
Company-wide AI enablement with a self-improving knowledge system
I designed and built Amplify-Knowledge, a Claude-based knowledge and delivery system that keeps itself current with every product release. Over 50 colleagues use it, and it improved delivery by a further 50–70%.
- Organisation
- Amplify-Now
- My role
- Initiator, architect and builder
- When
- 2026 – present
- 50–70%delivery improvement
- 50+users across every function
- 3 hrsclient-demo report (was a couple of days)
- 2–3 daysSSRS ticket (was 2–3 weeks)
- Routersmall always-loaded map + instructions
- Knowledge layersbusiness logic · code · data model · Power BI; loaded only when needed
- Delivery skillsanalyse ticket → check data → build → QA → update ticket
- Human gatenothing is posted without approval
Corrections and newly found bugs become skill-gap tickets. Once approved, they are folded into the next release.
The problem
Amplify is an enterprise strategy-execution SaaS platform with a monthly release train. The knowledge needed to deliver for clients was scattered and went stale every release. It covered business logic, application code, a large multi-tenant data model, Power BI semantic models and client-specific setups. Every report, support answer and product change started with someone re-discovering how things actually worked.
What I built
After a couple of months of prototyping locally, I designed, orchestrated and built Amplify-Knowledge, a file-based knowledge and delivery system on Claude.
- Router + lazy loading instead of one giant prompt. A short mapping file and the general instructions are always loaded. Everything else is read only when a task needs it: business logic and expected behaviour, code and infrastructure, every table, view, column and key of the data model, and the standard and per-client Power BI models.
- Skills across the delivery lifecycle. Separate skills analyse the GitLab ticket, query the database to confirm the data is ready, build the report, run QA (SQL ground truth against DAX, rendered checks, browser tests with PII redaction) and update the ticket.
- Orchestrator and specialist workers. A top-tier model plans and judges, and cheaper workers gather evidence. I tested this set-up: a coordinated team of specialist agents passed QA on a real ticket with fewer tokens than a single top-tier agent, which failed.
- Release refresh. On each release it confirms what actually shipped, from tickets, tags, production databases and client configuration. It reads only the delta and folds it into the knowledge base in about an hour.
- Self-improving protocol. When a person corrects it, or it finds a bug its documents don’t cover, it raises a skill-gap ticket with a proposed fix. I approve each fix before it goes into the next release.
- Guardrails built into the code. Tools are read-only by construction, product-owned rules sit behind an approval gate, client-facing documents are scanned for leaks, and a human approves anything before it is posted.
Who uses it
More than 50 people across every function:
- Support answers client questions, queries databases and troubleshoots.
- Reporting uses it for the full Power BI development cycle.
- Product goes from idea to development tickets, change plans, release notes and client knowledge-base articles.
- Developers find the smallest change path across modules and QA it.
Outcome
Delivery improved by a further 50–70%, measured on tickets resolved per day, week and month, QA rounds per ticket and developer-days per ticket.
| Work item | Before | After |
|---|---|---|
| SSRS report ticket | 2–3 weeks | 2–3 days |
| Bespoke Power BI dashboard | 3–5 weeks | 3–4 days |
| Quick report for a client demo | a couple of days | 3 hours |
| Backlog wait before pick-up | 7–10 days | ~3 days |