Sentinel-IR-MCP: Wenn mehrere KI-Agenten denselben Code untersuchen
Mit Sentinel-IR-MCP in Version 0.2.2 steht ein Werkzeug bereit, mit dem mehrere KI-Agenten einen Codebase untersuchen. Das Projekt zeigt, welche verborgenen Probleme dabei auftreten koennen.
Danke für die Unterstützung. Veröffentlichung: "Sentinel-IR-MCP v0.2.2 auf GitLab".
Paket: "sentinel-ir-MCP@0.2.2 auf npm".
Stellen Sie sich vor, man beauftragt eine KI, ein Softwareprojekt zu untersuchen. Sollte sie jede Zeile Code lesen, eine kurze Zusammenfassung erhalten oder mit einer Zusammenfassung beginnen und den Originalcode erst öffnen, wenn sie weitere Beweise benötigt?
Ich habe diese drei Ansätze mit Sentinels Live-Benchmark und GPT-6 Astra getestet. Über 87 Fragen hinweg beantwortete der Vollcode-Ansatz 84 korrekt, der Ansatz mit kompakten Informationen 82 und ließ fünf ungelöst, während der hybride Ansatz alle 87 korrekt beantwortete.
Der hybride Ansatz verbrauchte außerdem schätzungsweise etwa 71 Prozent weniger Eingabe-Tokens als der Vollcode-Ansatz. Dies ist ein vielversprechendes Ergebnis aus einem kontrollierten Test, kein Beweis dafür, dass KI-Agenten nun fehlerfrei arbeiten.
"Lesen Sie den Original-Benchmark und prüfen Sie die Daten selbst."
Stellen Sie sich vor, Ihr Unternehmen beauftragt einen Ermittler mit der Untersuchung eines Softwareprojekts, bevor es in Produktion geht.
Der Ermittler hat eine klare Aufgabe:
Herauszufinden, was das Programm tut, worauf es zugreifen kann, ob es über ein Netzwerk kommuniziert, ob es Dateien schreibt und ob es Operationen enthält, die besondere Aufmerksamkeit verdienen.
Das Projekt umfasst Hunderte oder Tausende Zeilen Code. Der Ermittler kann nicht einfach den Namen des Projekts betrachten und wissen, was darin geschieht. Er braucht Beweise.
Stellen Sie sich nun vor, man gibt drei Versionen desselben Ermittlers dieselbe Aufgabe.
Der erste erhält jedes Originaldokument.
Der zweite erhält einen im Voraus erstellten strukturierten Bericht.
Der dritte beginnt mit dem Bericht, kann aber zu den Originaldokumenten zurückkehren, wenn der Bericht nicht genügend Informationen enthält.
Das ist die zentrale Frage hinter meinem Sentinel-Benchmark.
Hier gibt es einen wichtigen Unterschied: Es handelt sich nicht um drei unabhängige KI-Agenten, die miteinander streiten oder Nachrichten austauschen. Der Benchmark vergleicht drei Arten, Informationen an dasselbe benannte Modell, GPT-6 Astra, zu liefern.
Der Unterschied liegt nicht einfach darin, wie intelligent der Ermittler ist. Es geht darum, wie viele relevante Beweise der Ermittler erhält und wie das System reagiert, wenn diese Beweise unzureichend sind.
Das Modell erhält den Original-Quellcode und beantwortet Fragen dazu.
Denken Sie an einen Detektiv, der die komplette Akte erhält, einschließlich Zeugenaussagen, Fotografien, Berichte und jede Seite unterstützender Beweise.
Nichts muss zusammengefasst werden, bevor der Detektiv mit seiner Arbeit beginnt.
Das hat einen offensichtlichen Vorteil. Das relevante Detail könnte an einem unerwarteten Ort verborgen sein, und das Originalmaterial steht zur Einsicht zur Verfügung.
Jedes Mal, wenn das Modell eine Frage untersuchen muss, kann die bereitgestellte Information viel mehr Material enthalten, als die Frage tatsächlich erfordert.
Angenommen, Sie fragen, ob ein Programm einen HTTP-Endpunkt bereitstellt. Die Antwort könnte in einer Handvoll Zeilen sichtbar sein. Dennoch erhält das Modell möglicherweise auch Code, der für unabhängige Berechnungen, Formatierung, Protokollierung und andere Operationen zuständig ist.
Das zusätzliche Material ist nicht unbedingt schädlich. Es ist einfach nicht immer für die aktuelle Frage relevant.
In KI-Systemen werden die einem Modell bereitgestellten Informationsstücke oft als Tokens dargestellt. Tokens sind die Einheiten, die Modelle verarbeiten, wenn sie Text lesen und Antworten erzeugen.
Eine größere Eingabe kann mehr Verarbeitung erfordern und die Nutzungskosten erhöhen, abhängig vom Modell und Dienst.
Der wichtige Punkt ist, dass es nicht automatisch dasselbe ist, einer KI mehr Informationen zu geben, ihr bessere Informationen zu geben.
Manchmal enthalten die zusätzlichen Seiten genau das, was der Ermittler braucht. Manchmal sind die meisten davon für die Frage irrelevant.
Der zweite Ansatz heißt IR, kurz für Intermediate Representation.
Statt nur den Originalcode zu erhalten, bekommt das Modell eine strukturierte Beschreibung wichtiger Fakten, die aus diesem Code extrahiert wurden.
Stellen Sie sich vor, Sie erhalten den Grundriss eines Gebäudes, anstatt jeden Raum untersuchen zu müssen, bevor Sie eine einfache Frage beantworten.
Der Plan könnte Eingänge, Ausgänge, Elektro-räume und die Lage abgesperrter Bereiche ausweisen. Viele Fragen lassen sich anhand dieser Karte beantworten, ohne das gesamte Gebäude erkunden zu müssen.
Sentinel-IR wendet eine ähnliche Idee auf Software an.
Das bedeutet mehr, als eine KI zu bitten, eine kürzere Version einer langen Datei zu schreiben.
Eine normale Zusammenfassung könnte lauten: "Dieses Programm betreibt einen Server und verarbeitet Anfragen."
Eine strukturierte Repräsentation kann stattdessen einzelne Routen, importierte Module, Operationen und andere spezifische Fakten in einem vorhersagbaren Format erfassen.
Der Unterschied ist wichtig, weil von der KI nicht mehr erwartet wird, jedes strukturelle Detail aus dem Originaltext wiederzuentdecken, wann immer sie eine Frage beantworten muss.
Eine Karte ist nur nützlich, wenn sie die wichtigen Merkmale des Gebiets korrekt erfasst.
Wenn eine relevante Operation in der Repräsentation fehlt, sieht das Modell möglicherweise nie die Beweise, die es braucht. Und wenn die Repräsentation etwas zu stark vereinfacht, könnte das Modell zu einer falschen Schlussfolgerung gelangen.
Eine kompakte Repräsentation ist daher nicht automatisch eine bessere Repräsentation.
Es muss die Informationen bewahren, die wichtig sind.
An dieser Stelle wird die Geschichte interessant.
Menschen nehmen oft an, dass eine komprimierte oder zusammengefasste Version von etwas immer kleiner sein muss als das Original.
Das gilt nicht für strukturierte Software-Informationen.
In einem kleinen Beispiel des veröffentlichten Benchmarks hatte ein 27 Zeilen langer HTTP-Server eine geschätzte Eingabegröße von 163 Tokens für den Originalquelltext und 272 Tokens für seine IR-Darstellung.
Der Grund dafür war, dass die Originaldatei bereits relativ klein war. Ein strukturierter Bericht benötigt zudem Bezeichnungen, Feldnamen, Listen und Beschreibungen, damit seine Fakten für das Modell verständlich sind.
Diese zusätzlichen Elemente können mehr kosten als der ursprüngliche Text, wenn die Quelle kurz ist.
Für eine Stichprobe von ungefähr 393 Zeilen verzeichnet der Benchmark geschätzte 2.861 Tokens für den Quelltext und 734 für die IR-Darstellung.
Für eine Stichprobe von ungefähr 951 Zeilen lauten die Zahlen 7.186 Tokens für den Quelltext und 498 für die IR-Darstellung.
Plötzlich ist die Karte viel kleiner als das Gebiet.
Das ist der praktische Grund, diesen Ansatz zu untersuchen.
Es ist kein Versprechen, dass jede Datei schrumpfen wird. Es ist ein Versuch, nicht wiederholt große Mengen an Quellcode zu übermitteln, wenn ein kompakter Satz relevanter Fakten die Frage beantworten kann.
Je größer der Unterschied zwischen dem Originalmaterial und den für eine Aufgabe benötigten nützlichen Informationen ist, desto größer kann die Möglichkeit sein, Eingabe-Tokens zu sparen.
Es kombiniert die beiden vorherigen Ansätze.
Das Modell beginnt mit strukturierten Informationen. Wenn diese Informationen nicht ausreichen, kann der Workflow eskalieren und den Originalquelltext konsultieren.
Der Prüfer beginnt mit einem Grundriss. Er zeigt die wichtigsten Eingänge, Ausgänge und Sperrbereiche.
Die meisten Fragen lassen sich anhand des Plans leicht beantworten.
Doch dann bemerkt der Prüfer eine Tür, die in einen als gesperrt markierten Raum führt. Der Plan identifiziert die Tür, aber er erklärt nicht, was im Inneren des Raums geschieht.
Man beantragt Zugang zum ursprünglichen Beweismaterial.
Das ist die Idee hinter dem hybriden Ansatz: kompakte Informationen verwenden, wo sie ausreichen, und einen Weg zurück zum Originalquelltext offenhalten, wenn mehr Details benötigt werden.
Das unterscheidet sich von der Wahl zwischen zwei Extremen.
Das System muss nicht jedes Mal alles übermitteln, und es muss nicht so tun, als enthalte seine anfängliche Zusammenfassung jede mögliche Antwort.
Im Benchmark verzeichnete die Variante IR + RAW 93 Modellaufrufe für 87 Fragen. Das bedeutet sechs zusätzliche Aufrufe über den Baseline von einem Aufruf pro Frage hinaus, was mit der gezielten Eskalation in diesem Test übereinstimmt.
Diese zusätzliche Arbeit ist wichtig. Der Zugriff auf den Originalquelltext ist nicht kostenlos, und zusätzliche Aufrufe können Zeit kosten.
Aber auch eine falsche Antwort ist nicht kostenlos. In einem Software-Sicherheits-Workflow kann eine falsche Schlussfolgerung über eine gefährliche Operation weitaus teurer sein als eine zusätzliche Untersuchung.
Die eigentliche Designfrage lautet daher nicht: Wie können wir jeden zusätzlichen Aufruf vermeiden?
Sie lautet: Wann lohnt sich der zusätzliche Aufruf?
Der veröffentlichte Sentinel-Benchmark hält einen Live-Lauf mit GPT-6 Astra über 87 Fragen fest.
Ansatz| Richtige Antworten| Ungelöst| Geschätzte Eingabe-Tokens RAW| 84 von 87| 0| 279.476 IR| 82 von 87| 5| 58.549 IR + RAW| 87 von 87| 0| 80.340
Die vom Benchmark berichteten Genauigkeitswerte liegen bei 96,6 Prozent für RAW, 94,3 Prozent für IR und 100 Prozent für IR + RAW.
Die Unterschiede verraten uns etwas Wichtiges.
Erstens reduzierte die kompakte Darstellung das gemessene Eingabevolumen erheblich.
IR verwendete etwa 79 Prozent weniger geschätzte Eingabe-Tokens als RAW.
Zweitens bedeutete ein reduziertes Eingabevolumen nicht automatisch die vollständige Beibehaltung des Ergebnisses.
Der eigenständige IR-Ansatz ließ fünf Fragen ungelöst. Er verwendete weniger Eingaben, aber er beantwortete nicht jede Frage.
Drittens holte der hybride Ansatz in diesem speziellen Lauf die fehlenden Antworten zurück.
IR + RAW verwendete etwa 71 Prozent weniger geschätzte Eingabe-Tokens als RAW und beantwortete gemäß den erwarteten Antworten des Benchmarks alle 87 Fragen korrekt.
Die Ergebnisse unterstützen eine weitere Untersuchung eines Systems, das kompakte Fakten mit Zugriff auf ursprüngliche Beweise kombiniert.
Sie belegen nicht, dass der hybride Ansatz immer besser abschneiden wird als die Alternativen, oder dass er bereit ist, unbeaufsichtigte Produktionsentscheidungen zu treffen.
Siebenundachtzig Fragen sind ein nützlicher Beleg, keine Garantie für jede mögliche Codebasis.
Bei der Interpretation dieser Ergebnisse gibt es eine technische Einschraenkung, die beachtet werden muss.
Der Benchmark schaetzt die Token-Anzahl ueber die Laenge des Textes geteilt durch vier. Diese Naeherung wird konsistent ueber alle Varianten hinweg angewendet.
Diese Zahlen eignen sich daher, um die ungefaehre Groesse ihrer Eingaben zu vergleichen. Sie sind keine exakten Messungen der tatsaechlichen Tokenisierung des Modells oder der Kosten, die ein KI-Anbieter berechnet.
Der Unterschied ist relevant, weil echte Token-Anzahlen je nach Inhalt und Tokenizer variieren, und die Kosten zusaetzlich vom Modell sowie von der Preisgestaltung des Dienstes abhaengen.
Die in diesem Durchlauf gemessenen Zeiten unterstreichen einen weiteren Punkt: Weniger geschaetzte Eingabe-Tokens machten den hybriden Workflow nicht automatisch zum schnellsten.
Die erfassten Laufzeiten betrugen rund 155 Sekunden fuer RAW, 147 Sekunden fuer IR und 159 Sekunden fuer IR + RAW. Es handelt sich um Messungen dieses konkreten Durchlaufs, nicht um allgemeine Leistungsgarantien.
Das staerkste Ergebnis lautet hier also nicht, dass das Hybridsystem immer guenstiger, schneller oder genauer ist.
Sondern dass diese hybride Konfiguration alle getesteten Fragen korrekt beantwortet hat und dabei deutlich weniger geschaetzte Eingabe-Tokens verwendete als der Ansatz mit den vollstaendigen Quelldaten.
Das ist auch eine deutlich nuetzlichere Aussage, als einfach zu verkuenden, KI sei schlauer geworden.
Man stelle sich nun vor, dasselbe System auf ein echtes Softwareprojekt anzuwenden.
Ein Programm koennte einen API-Schluessel einlesen, ueber ein Netzwerk kommunizieren, Dateien schreiben oder einen anderen Prozess starten. Diese Operationen koennen legitim sein. Ihre bloesse Anwesenheit beweist nicht, dass ein Programm boesartig ist.
Aber sie koennen eine Rolle spielen, wenn man bewertet, was das Programm tun kann und was schiefgehen koennte.
Ein KI-System, das das Projekt untersucht, muss mehrere Dinge voneinander unterscheiden:
Welche Schlussfolgerungen erlauben die verfuegbaren Belege?
Und wann sollte das System eine sichere Aussage verweigern?
Ein Bericht, der eine Prozessstart-Operation identifiziert, ist ein Beleg fuer die Struktur des Programms. Er ist fuer sich genommen kein vollstaendiges Sicherheitsurteil.
Ebenso beweist eine fehlende Feststellung nicht, dass eine Operation nicht existiert, sofern die Analysemethode nicht zuverlaessig genug ist, um diese Schlussfolgerung zu stuetzen.
Deshalb benoetigen kompakte Repraesentationen mehr als clevere Kompression. Sie benoetigen eine akkurate Extraktion, sorgfaeltig definierte Fakten und eine Moeglichkeit, mit fehlenden Informationen umzugehen.
Ein Ergebnis, das in einer Demo beeindruckend wirkt, muss gegen bekannte Antworten, schwierige Faelle und Situationen getestet werden, in denen das System einraeumen sollte, dass es nicht genug weiss.
Der Benchmark ist ein kleines Beispiel dafuer, diese Designfrage mit konkreten Fragen und protokollierten Antworten zu pruefen, statt sich allein auf eine ueberzeugende Demonstration zu verlassen.
Die groessere Idee reicht weit ueber Quellcode hinaus.
KI-Agenten arbeiten zunehmend mit Dokumenten, Datenbanken, Websites, Tools und Informationen, die sich ueber mehrere Schritte hinweg ansammeln.
In all diesen Szenarien muss das System entscheiden, welche Informationen verfuegbar gehalten werden, welche abgerufen werden sollen und was zu tun ist, wenn die Belege unvollstaendig sind.
Man denke an einen Kundenservice-Agenten, der eine verspaetete Bestellung untersucht. Er braucht moeglicherweise nicht die gesamte Historie des Kunden. Er braucht die Bestellnummer, den Versandstatus, relevante Updates und vielleicht Zugriff auf die urspruenglichen Aufzeichnungen, wenn eine Unstimmigkeit auftaucht.
Man denke an einen Forschungs-Agenten. Er beginnt moeglicherweise mit Notizen und extrahierten Erkenntnissen und oeffnet dann das zugrundeliegende Papier erneut, um ein wichtiges Detail zu ueberpruefen.
Man denke an einen KI-Coding-Assistenten. Er braucht moeglicherweise eine kompakte Uebersicht eines Repositories, bevor er eine Aenderung vornimmt, sollte aber dennoch die tatsaechliche Implementierung pruefen, bevor er eine kritische Funktion veraendert.
Dies sind Beispiele fuer dasselbe Designprinzip, keine Ergebnisse, die dieser konkrete Benchmark belegt.
Es gibt auch eine breitere Lehre im Hinblick auf mehrere Agenten.
Mehr KI-Agenten hinzuzufuegen macht ein System nicht automatisch besser. Agenten brauchen nuetzliche Informationen, klare Zuständigkeiten, zuverlaessige Kommunikation und eine Moeglichkeit, Fehler zu erkennen. Andernfalls kann ein groesseres System schlicht mehr Moeglichkeiten fuer Verwirrung schaffen.
Manchmal ist die Antwort, einen weiteren Agenten hinzuzufuegen. Manchmal besteht sie darin, dem bestehenden Agenten bessere Belege zu geben. Und manchmal darin, ein deterministisches Werkzeug zu verwenden, statt ein Modell etwas schliessen zu lassen, was sich direkt ueberpruefen laesst.
Bei Sentinel lautet die Frage enger gefasst: Kann eine strukturierte Repraesentation genug Informationen fuer viele Fragen der Software-Inspektion liefern und gleichzeitig einen Rueckweg zum Originalcode bewahren, wenn sie es nicht kann?
Der Live-Benchmark liefert ein ermutigendes Ergebnis fuer diesen Ansatz. Der naechste Schritt ist, das Experiment ueber mehr Projekte, mehr Fragen, verschiedene Arten von Code und unabhaengige Durchlaeufe hinweg zu wiederholen und dabei, wo moeglich, den tatsaechlichen Token-Verbrauch und die Kosten zu messen.
So wird aus einem vielversprechenden Ergebnis belastbarere Ingenieurs-Belege.
Dem Untersucher jedes Dokument zu geben, kann funktionieren, ist aber moeglicherweise verschwenderisch.
Ihm nur eine Zusammenfassung zu geben, kann effizient sein, hinterlaesst aber moeglicherweise wichtige Fragen ohne Antwort.
Ihm eine strukturierte Uebersicht und die Moeglichkeit zu geben, die Originalbelege zu inspizieren, bietet eine weitere Moeglichkeit.
Der Untersucher kann die Uebersicht fuer gewoehnliche Fragen nutzen und bei Bedarf zu den Belegen zurueckkehren.
Das ist die Idee hinter Sentinels IR + RAW Ansatz.
Das Ziel ist nicht, eine KI durch weniger Information clever erscheinen zu lassen. Das Ziel ist, ihr die richtigen Informationen fuer die Aufgabe zu geben, zu erkennen, wann diese unzureichend sind, und weitergehende Untersuchungen zu ermoeglichen.
Der Benchmark mit 87 Fragen beweist nicht, dass dieser Ansatz universell ueberlegen ist. Er zeigt aber, warum der Ansatz eine weitere Pruefung verdient.
Und es wirft eine Frage auf, die weit über die Softwaresicherheit hinausreicht:
Wenn wir KI-Agenten bauen, sollten wir uns nur darauf konzentrieren, dass sie besser denken, oder sollten wir auch verbessern, wie sie Beweise aufnehmen, Unsicherheit erkennen und entscheiden, wann weitere Untersuchungen nötig sind?
Ich bin der Meinung, dass der zweite Teil weit mehr Aufmerksamkeit verdient.
Denn ein intelligenter Ermittler mit unvollständigen Beweisen kann trotzdem zur falschen Schlussfolgerung gelangen. Ein gut gestalteter Untersuchungsprozess gibt diesem Ermittler die Chance herauszufinden, was fehlt.
Zehn Artikel und Forschungspapiere, die sich als Nächstes zu lesen lohnen
Der Sentinel-Benchmark untersucht ein bestimmtes Problem: wie ein KI-System Informationen verwendet. Diese zehn Ressourcen beleuchten verwandte Herausforderungen, von der Kontextauswahl und Multi-Agenten-Koordination bis hin zu Sicherheit und Evaluierung.
"Effective Context Engineering for AI Agents — Anthropic" ( https://www.anthropic.com/research/effective-context-engineering-for-ai-agents ) Warum die Informationen, die einem Modell zugeführt werden, während der gesamten Arbeit eines Agenten verwaltet werden müssen und nicht nur in einen guten ersten Prompt geschrieben werden sollten.
"Towards a Science of Scaling Agent Systems — Google Research" ( https://research.google/blog/towards-a-science-of-scaling-agent-systems-when-and-why-agent-systems-work/ ) Forschung dazu, wann mehrere Agenten die Leistung verbessern und wann Koordination ein System sogar verschlechtern kann.
"A Practical Guide to Building AI Agents — OpenAI" ( https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/ ) Eine praxisnahe Einführung in Agentenarchitektur, Tools, Workflows und Sicherheitsvorkehrungen.
"ContextBench: A Benchmark for Context Retrieval in Coding Agents" ( https://arxiv.org/abs/2602.05892 ) Forschung, die untersucht, ob Coding-Agenten beim Lösen von Problemen die relevanten Teile einer Codebasis abrufen und verwenden.
"SWE Context Bench: A Benchmark for Context Learning in Coding" ( https://arxiv.org/abs/2602.08316 ) Forschung zur Wiederverwendung früherer Erfahrungen und Zusammenfassungen über verwandte Coding-Aufgaben hinweg, einschließlich der Risiken, falsche Informationen abzurufen.
"AgentBench: Evaluating LLMs as Agents" ( https://proceedings.iclr.cc/paper_files/paper/2024/hash/e9df36b21ff4ee211a8b71ee8b7e9f57-Abstract-Conference.html ) Ein Benchmark, der bewertet, wie Sprachmodelle in interaktiven Umgebungen schlussfolgern, Anweisungen befolgen und handeln.
"Systematic Debugging for AI Agents: Introducing AgentRx — Microsoft Research" ( https://www.microsoft.com/en-us/research/blog/systematic-debugging-for-ai-agents-introducing-the-agentrx-framework/ ) Wie man herausfindet, an welcher Stelle ein langer KI-Agenten-Workflow fehlgeschlagen ist, statt nur auf das Endergebnis zu schauen.
"Know Your Limits: A Survey of Abstention in Large Language Models" ( https://aclanthology.org/2025.tacl-1.26/ ) Forschung dazu, wann eine KI darauf verzichten sollte zu antworten, weil sie keine hinreichend verlässliche Antwort liefern kann.
"OWASP Top 10 for Agentic Applications 2026" ( https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/ ) Sicherheitsrisiken im Zusammenhang mit KI-Systemen, die planen, Tools nutzen und Aktionen ausführen können.
"Evaluate Agent Workflows — OpenAI" ( https://developers.openai.com/api/docs/guides/agent-evals ) Praxisnahe Anleitung zur Evaluierung von Agentenläufen, zur Untersuchung von Fehlern und zum Testen, ob Änderungen einen Workflow tatsächlich verbessern.
Die Zahlen in diesem Artikel stammen aus dem veröffentlichten Sentinel-Live-Benchmark. Die Interpretation der Ergebnisse ist bewusst auf dieses Experiment beschränkt; weitergehende Aussagen zu Leistung, Sicherheit und Kosten erfordern zusätzliche Tests.
Original-Benchmark: https://dev.to/jackymencz/sentinel-benchmark-livejson-ifl
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Thanks for support.. Release: "Sentinel-IR-MCP v0.2.2 on GitLab" ( https://gitlab.com/jakubrojicek11/sentinel-ir-mcp/-/tree/v0.2.2?ref_type=tags )
Package: " sentinel-ir-mcp@0.2.2 on npm" ( https://www.npmjs.com/package/sentinel-ir-mcp/v/0.2.2 )
Imagine asking an AI to investigate a software project. Should it read every line of code, receive a short summary, or start with a summary and open the original code only when it needs more evidence?
I tested these three approaches using Sentinel's live benchmark with GPT-6 Astra. Across 87 questions, the full-code approach answered 84 correctly, the compact-information approach answered 82 and left five unresolved, while the hybrid approach answered all 87 correctly.
The hybrid approach also used approximately 71% fewer estimated input tokens than the full-code approach. This is a promising result from one controlled test, not proof that AI agents are now error-free.
"Read the original benchmark and inspect the data yourself." ( https://dev.to/jackymencz/sentinel-benchmark-livejson-ifl )
Imagine your company hires an investigator to inspect a software project before it goes into production.
The investigator has a straightforward assignment:
Find out what the program does, what it can access, whether it communicates over a network, whether it writes files, and whether it contains operations that deserve extra attention.
The project contains hundreds or thousands of lines of code. The investigator cannot simply look at the name of the project and know what happens inside it. They need evidence.
Now imagine giving three versions of the same investigator the same assignment.
The first receives every original document.
The second receives a structured report prepared in advance.
The third starts with the report but can return to the original documents when the report does not contain enough information.
That is the central question behind my Sentinel benchmark.
There is an important distinction here: these are not three independent AI agents arguing with one another or exchanging messages. The benchmark compares three ways of supplying information to the same named model, GPT-6 Astra.
The difference is not simply how intelligent the investigator is. It is how much relevant evidence the investigator receives, and how the system responds when that evidence is insufficient.
The model receives the original source code and answers questions about it.
Think of a detective who receives the complete case file, including witness statements, photographs, reports, and every page of supporting evidence.
Nothing needs to be summarized before the detective begins.
This has an obvious advantage. The relevant detail might be buried in an unexpected place, and the original material is available for inspection.
Every time the model needs to investigate a question, the supplied information can contain much more material than that question actually requires.
Suppose you ask whether a program exposes an HTTP endpoint. The answer might be visible in a handful of lines. Yet the model may also receive code responsible for unrelated calculations, formatting, logging, and other operations.
The extra material is not necessarily harmful. It is simply not always relevant to the current question.
In AI systems, the pieces of information supplied to a model are often represented as tokens. Tokens are the units models process when reading text and producing responses.
A larger input can require more processing and may increase usage costs, depending on the model and service.
The important point is that giving an AI more information is not automatically the same as giving it better information.
Sometimes, the extra pages contain exactly what the investigator needs. Sometimes, most of them are irrelevant to the question.
The second approach is called IR, short for Intermediate Representation.
Instead of receiving only the original code, the model receives a structured description of important facts extracted from that code.
Imagine receiving a building's floor plan rather than having to inspect every room before answering a basic question.
The plan might identify the entrances, exits, electrical rooms, and locations of restricted areas. You can answer many questions from that map without exploring the entire building.
Sentinel-IR applies a similar idea to software.
This is more than asking an AI to write a shorter version of a long file.
A normal summary might say, "This program runs a server and processes requests."
A structured representation can instead record individual routes, imported modules, operations, and other specific facts in a predictable format.
The distinction matters because the AI is no longer expected to rediscover every structural detail from the original text whenever it needs to answer a question.
A map is only useful if it accurately records the important features of the territory.
If a relevant operation is missing from the representation, the model may never see the evidence it needs. And if the representation simplifies something too aggressively, the model might reach the wrong conclusion.
A compact representation is therefore not automatically a better representation.
It must preserve the information that matters.
This is where the story becomes interesting.
People often assume that a compressed or summarized version of something must always be smaller than the original.
That is not true for structured software information.
In one small example in the published benchmark, a 27-line HTTP server had an estimated input size of 163 tokens for the original source and 272 tokens for its IR representation.
Because the original file was already relatively small. A structured report also needs labels, field names, lists, and descriptions to make its facts understandable to the model.
Those additional elements can cost more than the original text when the source is short.
For a sample of approximately 393 lines, the benchmark records an estimated 2,861 tokens for the source and 734 for the IR representation.
For a sample of approximately 951 lines, the figures are 7,186 tokens for the source and 498 for IR.
Suddenly, the map becomes much smaller than the territory.
That is the practical reason to investigate this approach.
It is not a promise that every file will shrink. It is an attempt to avoid repeatedly sending large amounts of source code when a compact set of relevant facts can answer the question.
The larger the difference between the original material and the useful information required for a task, the more opportunity there may be to save input tokens.
It combines the two previous approaches.
The model starts with structured information. When that information is not sufficient, the workflow can escalate and consult the original source.
The inspector begins with a floor plan. It shows the main entrances, exits, and restricted areas.
Most questions are easy to answer from the plan.
But then the inspector notices a door leading into a room marked as restricted. The plan identifies the door, but it does not explain what happens inside the room.
They request access to the original evidence.
That is the idea behind the hybrid approach: use compact information where it is enough, and retain a path back to the original source when more detail is required.
This is different from choosing between two extremes.
The system does not have to send everything every time, and it does not have to pretend that its initial summary contains every possible answer.
In the benchmark, the IR + RAW variant recorded 93 model calls for 87 questions. That means six additional calls beyond the one-call-per-question baseline, consistent with targeted escalation in this test.
This additional work matters. Access to the original source is not free, and extra calls can add time.
But neither is a wrong answer free. In a software security workflow, an incorrect conclusion about a dangerous operation can be far more expensive than an additional investigation.
The real design question is therefore not, "How can we eliminate every extra call?"
It is, "When is the extra call worth making?"
The published Sentinel benchmark records a live run using GPT-6 Astra across 87 questions.
Approach| Correct answers| Unresolved| Estimated input tokens RAW| 84 of 87| 0| 279,476 IR| 82 of 87| 5| 58,549 IR + RAW| 87 of 87| 0| 80,340
The accuracy figures reported by the benchmark are 96.6% for RAW, 94.3% for IR, and 100% for IR + RAW.
The differences tell us something important.
First, the compact representation substantially reduced the measured input volume.
IR used approximately 79% fewer estimated input tokens than RAW.
Second, reduced input volume did not automatically preserve the full result.
The standalone IR approach left five questions unresolved. It used less input, but it did not answer every question.
Third, the hybrid approach recovered the missing answers in this particular run.
IR + RAW used approximately 71% fewer estimated input tokens than RAW and answered all 87 questions correctly according to the benchmark's expected answers.
The results support further investigation into a system that combines compact facts with access to original evidence.
They do not establish that the hybrid approach will always outperform the alternatives, or that it is ready to make unsupervised production decisions.
Eighty-seven questions are useful evidence, not a guarantee about every possible codebase.
There is a technical limitation that matters when interpreting these results.
The benchmark estimates token counts using the length of the text divided by four. It applies that approximation consistently across the variants.
These figures are therefore useful for comparing the approximate size of their inputs. They are not exact measurements of the model's actual tokenization or the money charged by an AI provider.
The distinction matters because real token counts vary with the content and tokenizer, and costs also depend on the model and the service's pricing.
The elapsed times in this run reinforce another point: fewer estimated input tokens did not automatically make the hybrid workflow the fastest.
The recorded elapsed times were approximately 155 seconds for RAW, 147 seconds for IR, and 159 seconds for IR + RAW. These are measurements from this particular run, not general performance guarantees.
So the strongest result here is not that the hybrid system is always cheaper, faster, or more accurate.
It is that this hybrid configuration answered all the tested questions correctly while using substantially fewer estimated input tokens than the full-source approach.
It is also a much more useful claim than simply announcing that AI has become smarter.
Now imagine applying the same system to a real software project.
A program might read an API key, communicate over a network, write files, or launch another process. These operations can be legitimate. Their presence alone does not prove that a program is malicious.
But they may matter when assessing what the program can do and what could go wrong.
An AI system investigating the project needs to distinguish between several things:
What does the available evidence allow us to conclude?
And when should the system refuse to make a confident claim?
A report identifying a process-launching operation is evidence about the program's structure. It is not, by itself, a complete security verdict.
Likewise, a missing finding does not prove that an operation is absent unless the analysis method is reliable enough to support that conclusion.
This is why compact representations need more than clever compression. They need accurate extraction, carefully defined facts, and a way to handle missing information.
A result that looks impressive in a demonstration must be tested against known answers, difficult cases, and situations where the system should admit that it does not know enough.
The benchmark is a small example of testing this design question with concrete questions and recorded answers rather than relying only on a persuasive demonstration.
The bigger idea extends beyond source code.
AI agents increasingly work with documents, databases, websites, tools, and information accumulated over multiple steps.
In all these settings, the system must decide what information to keep available, what to retrieve, and what to do when the evidence is incomplete.
Imagine a customer-support agent investigating a delayed order. It may not need the customer's entire history. It needs the order number, shipping status, relevant updates, and perhaps access to the original records when a discrepancy appears.
Imagine a research agent. It may start with notes and extracted findings, then reopen the underlying paper to verify an important detail.
Imagine an AI coding assistant. It may need a compact map of a repository before making a change, but it should still inspect the actual implementation before modifying a critical function.
These are examples of the same design principle, not results demonstrated by this particular benchmark.
There is also a broader lesson about multiple agents.
Adding more AI agents does not automatically make a system better. Agents need useful information, clear responsibilities, reliable communication, and a way to detect mistakes. Otherwise, a larger system can simply create more opportunities for confusion.
Sometimes the answer is to add another agent. Sometimes it is to give the existing agent better evidence. Sometimes it is to use a deterministic tool instead of asking a model to infer something that can be checked directly.
For Sentinel, the question is narrower: can a structured representation provide enough information for many software-inspection questions, while preserving a route back to the original code when it does not?
The live benchmark provides an encouraging result for that approach. The next step is to repeat the experiment across more projects, more questions, different kinds of code, and independent runs, while measuring actual token usage and costs where possible.
That is how a promising result becomes stronger engineering evidence.
Giving the investigator every document can work, but it may be wasteful.
Giving them only a summary can be efficient, but it may leave important questions unanswered.
Giving them a structured map and the ability to inspect original evidence offers another possibility.
The investigator can use the map for ordinary questions and return to the evidence when necessary.
That is the idea behind Sentinel's IR + RAW approach.
The goal is not to make an AI appear clever by giving it less information. The goal is to give it the right information for the task, recognize when that information is insufficient, and make further investigation possible.
The 87-question benchmark does not prove that this approach is universally superior. It does show why the approach deserves further testing.
And it raises a question that matters well beyond software security:
When we build AI agents, should we focus only on making them think better, or should we also improve how they receive evidence, recognize uncertainty, and decide when to investigate further?
I believe the second part deserves far more attention.
Because an intelligent investigator with incomplete evidence can still reach the wrong conclusion. A well-designed investigative process gives that investigator a chance to discover what is missing.
Ten articles and research papers worth reading next
The Sentinel benchmark explores one specific problem: how an AI system uses information. These ten resources examine related challenges, from context selection and multi-agent coordination to security and evaluation.
"Effective Context Engineering for AI Agents — Anthropic" ( https://www.anthropic.com/research/effective-context-engineering-for-ai-agents ) Why the information supplied to a model needs to be managed throughout an agent's work, not just written into a good initial prompt.
"Towards a Science of Scaling Agent Systems — Google Research" ( https://research.google/blog/towards-a-science-of-scaling-agent-systems-when-and-why-agent-systems-work/ ) Research on when multiple agents improve performance and when coordination can make a system worse.
"A Practical Guide to Building AI Agents — OpenAI" ( https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/ ) A practical introduction to agent architecture, tools, workflows, and safeguards.
"ContextBench: A Benchmark for Context Retrieval in Coding Agents" ( https://arxiv.org/abs/2602.05892 ) Research examining whether coding agents retrieve and use the relevant parts of a codebase when solving problems.
"SWE Context Bench: A Benchmark for Context Learning in Coding" ( https://arxiv.org/abs/2602.08316 ) Research on reusing previous experience and summaries across related coding tasks, including the risks of retrieving the wrong information.
"AgentBench: Evaluating LLMs as Agents" ( https://proceedings.iclr.cc/paper_files/paper/2024/hash/e9df36b21ff4ee211a8b71ee8b7e9f57-Abstract-Conference.html ) A benchmark evaluating how language models reason, follow instructions, and act across interactive environments.
"Systematic Debugging for AI Agents: Introducing AgentRx — Microsoft Research" ( https://www.microsoft.com/en-us/research/blog/systematic-debugging-for-ai-agents-introducing-the-agentrx-framework/ ) How to identify where a long AI-agent workflow failed instead of looking only at its final answer.
"Know Your Limits: A Survey of Abstention in Large Language Models" ( https://aclanthology.org/2025.tacl-1.26/ ) Research on when an AI should refrain from answering because it cannot provide a sufficiently reliable response.
"OWASP Top 10 for Agentic Applications 2026" ( https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/ ) Security risks associated with AI systems that can plan, use tools, and take actions.
"Evaluate Agent Workflows — OpenAI" ( https://developers.openai.com/api/docs/guides/agent-evals ) Practical guidance on evaluating agent runs, examining failures, and testing whether changes actually improve a workflow.
The numbers in this article come from the published Sentinel live benchmark. The interpretation of the results is deliberately limited to that experiment; broader performance, security, and cost claims require further testing.
Original benchmark: https://dev.to/jackymencz/sentinel-benchmark-livejson-ifl