Case: Agent performance analyse — Wopal inkooporder rapport

Datum: 23 maart 2026 Tags: agent-performance, mcp, rdlc, bottleneck, tooling-gap

Duurste agent calls

Agent taak	Duur	Tokens	Tool calls	Waarom zo duur?
RDLC kolommen herordenen (2e poging)	279s (~4.5 min)	92k	22	Elke TablixRow (26 rijen) moest individueel gelezen en ge-edit worden. XML cellen swappen vereist veel context + precise string matching.
RDLC kolommen herordenen (1e poging)	243s (~4 min)	48k	24	Zelfde probleem als hierboven.
RDLC kolommen + cellen toevoegen (punt 2,3,4)	791s (~13 min)	151k	112	26 rijen in de tablix, elk moest 2 extra cellen krijgen. 112 tool calls = 112 Read/Edit operaties op een 700KB XML bestand.
Zoek 4PS Element/FSC velden	107s	50k	43	Moest 4PS .app extracten en meerdere tabeldefinities doorzoeken zonder database.
Contact person fallback chain traceren	92s	47k	28	Meerdere tabellen (PurchaseHeader, ProjectPrincipal, Job, UserSetup, SalespersonPurchaser) doorlopen om de volledige dataketen te begrijpen.
Verify contact fields in 4PS	93s	47k	28	Zelfde patroon: veel tabellen doorzoeken in geëxtraheerde .app bestanden.

Root causes

1. RDLC tablix manipulatie is extreem duur (grootste bottleneck)

Probleem: Kolommen toevoegen of herordenen in een RDLC tablix vereist het aanpassen van ELKE rij. Bij 26 rijen × 2 cellen = 52+ individuele XML edits. Elke edit vereist: lees context → vind juiste positie → Edit tool call.

Waarom de MCP dit niet oploste: bc_extract_layout_spec gaf lege tablixes[] terug voor dit rapport omdat het een genest list-in-tablix patroon gebruikt. De round-trip (extract → modify → regenerate) was niet beschikbaar.

Verbetering: De layout spec extractor moet geneste tablix-patronen ondersteunen (list1 → PurchLines). Dit is het #1 verbeterpunt — als de round-trip had gewerkt, had de hele kolom-herordening 1 tool call gekost in plaats van 100+.

2. 4PS symbool lookups zonder database

Probleem: Veldtypes, FlowField definities, en TableRelations moesten opgezocht worden door .app bestanden handmatig te extracten en door te zoeken. Elke lookup = meerdere grep/read cycles.

Waarom de MCP dit niet oploste: bc_use_database gaf een schema error (no such column: field_type). De databases waren met een oudere bc-parse versie gescand.

Verbetering: Databases her-scannen met nieuwste bc-parse. Dan kan bc_query_object direct veldmetadata teruggeven inclusief FieldClass (FlowField/Normal), CalcFormula, en TableRelation.

3. Verkeerd textbox identificeren

Probleem: Zonder de layout spec moest een agent raden welk textbox het ordernr was op basis van GetData indices. Koos verkeerd (leveranciernaam i.p.v. ordernr). Kostte een hele debug-cyclus.

Waarom de MCP dit niet oploste: De MCP was nog niet actief. bc_parse_rdlc was beschikbaar maar werd niet aangeroepen.

Verbetering: Altijd bc_parse_rdlc gebruiken voor het identificeren van textboxen, zelfs voor "simpele" positiewijzigingen.

Aanbevolen verbeteringen

Prioriteit	Verbetering	Impact	Status
P0	Layout spec extractor: geneste tablix-patronen ondersteunen	Elimineert de duurste operatie (kolom toevoegen/herordenen) van 100+ calls naar 1 call	DONE
P1	Databases her-scannen met nieuwste bc-parse	Maakt bc_query_object bruikbaar voor veldmetadata lookups	DEELS
P2	bc_modify_rdlc MCP tool voor chirurgische operaties	Als de round-trip niet werkt, bied dan een operations-based API (add_column, reorder_columns, set_width)	VERVANGEN
P3	RDLC validator: false positive DATASET_NOT_IN_AL voor report extensions onderdrukken	Output was 110k chars, onbruikbaar zonder severity filter	DONE

Opgelost (23 maart 2026)

P0: Geneste tablix-patronen — DONE

findAllTablixes() in layout-spec-extractor.ts zoekt nu recursief door de hele XML boom. Ondersteunt het List > Rectangle > ReportItems > Tablix nesting patroon dat BC standaard rapporten gebruiken (bijv. list1 → list1_Contents → PurchLines). Wopal PurchLines wordt nu correct gevonden met alle 9 kolommen.

P1: Database schema mismatch — DONE (her-scan nog nodig)

SQL queries in base-app-queries.ts aligned met het daadwerkelijke bc-parse schema: data_type i.p.v. field_type, LEFT JOIN op field_properties voor Caption/FieldClass/CalcFormula. bc_use_database werkt nu zonder schema errors. De databases zelf moeten nog her-gescand worden met de nieuwste bc-parse voor complete metadata.

P2: bc_modify_rdlc — VERVANGEN door layout spec round-trip

Architectuurbesluit: in plaats van chirurgische XML operaties gebruiken we een declaratieve aanpak:

1. bc_extract_layout_spec — RDLC → JSON spec (kolommen, styling, groepen, page config)
2. Spec aanpassen (JSON manipulatie)
3. bc_generate_report_extension({ layoutSpec }) — JSON spec → complete RDLC

Dit elimineert de noodzaak voor 100+ Read/Edit calls. Eén round-trip in plaats van XML chirurgie.

P3: Validator false positives — DONE (drie fixes)

1. Severity filter: bc_validate_rdlc({ severity: "critical", maxIssues: 20 }) — beperkt output van 400+ issues naar alleen relevante items
2. UNUSED_DATASET_FIELD fix: Scant nu de rauwe XML voor Fields!X.Value patronen i.p.v. alleen het structurele model. Geen false positives meer voor velden in tablix cellen.
3. Extension-aware DATASET_NOT_IN_AL: Detecteert reportextensions en draait de check om — verifieert dat extensie-kolommen in de DataSet staan, flagged niet meer de 200+ base report velden.

MCP tools niet gebruikt — DONE

.claude/rules/rdlc-mcp-tools.md toegevoegd aan het alchemist project. Instrueert Claude om altijd MCP tools te gebruiken voor RDLC wijzigingen en nooit handmatig XML te editen.

Zoektermen

agent-performance, bottleneck, rdlc-tablix, kolom-herordenen, layout-spec, genest-tablix, round-trip, bc-parse-database, mcp-verbetering