Was hat sich in Oran 3.6 geändert?

Jede Version von Oran hat etwas hinzugefügt. Kostenzuordnung in 3.1, Budgets, die blockieren in 3.2, Bewertung in 3.3, Optimierung in 3.4, der Agent Hub in 3.5. Individuell nützlich, und bis vor Kurzem noch fünf Dinge, die ein Team zusammenbauen musste.

3.6 ist die Version, bei der die Montage aufhört und die Annahme beginnt.

Mehrere Integrationen

Die größte praktische Änderung ist die Reichweite. Ein Agent, der nur innerhalb eines Systems agieren kann, ist eher eine Demo eines Arbeitsablaufs als ein Teilnehmer daran, und die meisten echten Arbeiten durchlaufen drei oder vier Systeme, bevor sie abgeschlossen sind.

3.6 erweitert die Möglichkeiten, mit denen ein Agent verbunden werden kann, wobei an jeder Grenze die gleiche Governance gilt. Eine Verbindung ist keine Berechtigung: Ein Agent, der Lesezugriff auf ein Repository und keinen Schreibzugriff gewährt, kann nicht pushen, und dies wird dort erzwungen, wo die Aktion stattfindet, und nicht in einer Eingabeaufforderung angefordert.

Situationsbewusstsein

Frühere Versionen führten einen Plan aus. 3.6 verfolgt, was innerhalb eines Laufs bereits passiert ist und was sich während des Laufs darunter geändert hat.

Das ist wichtig für den unrühmlichen Misserfolg, der das meiste Geld verschwendet: ein Agent, der weiterhin einen Plan ausführt, der auf einem Staat basiert, der inzwischen umgezogen ist. Das Wiederholen eines bereits erfolgreichen Schritts oder das Handeln auf der Grundlage einer Aufzeichnung, die jemand anders inzwischen geändert hat, erzeugt Arbeit, die von einer Person rückgängig gemacht werden muss. Bemerken ist billiger als reparieren.

Erweiterte Agentenverwaltung

Die Konsolidierung ist hier am deutlichsten sichtbar. Ein Agent erhält nun Eigentum, Grenzen, Budget und Bewertung als Eigenschaften und nicht als separate Konfigurationsübungen.

In der Praxis ist es das, was das Neunzig-Tage-Muster, über das wir immer wieder schreiben, verändert. Die Zersiedelung, die sich in der vierten Woche zeigt, ist nur dann ein Problem, wenn Zuschreibung und Eigentum nachträglich angepasst werden. Wenn es sich um die Standardform eines Agenten handelt, handelt es sich bei dreißig Agenten eher um eine Bestandsaufnahme als um ein Mysterium.

Kostentransparenz und -kontrolle vereint

3.1 Ausgaben sichtbar gemacht. 3,2 machten es stoppbar. 3.6 stellt beides auf die gleiche Stufe wie die Bewertung, die feststellt, ob eine Ersparnis real war.

Diese Kombination ist der Punkt. Eine Kostensenkung ohne Bewertung führt zu einem günstigeren Ergebnis unbekannter Qualität, was keine Ersparnis, sondern einen Aufschub darstellt. Der Optimierer schlägt Modell-, Eingabeaufforderungs- und Tooländerungen vor, und jeder Vorschlag wird anhand Ihrer eigenen Bewertungen bewertet, bevor er gültig ist.

Was es nicht tut

Es führt weder Ihren Code zusammen, noch genehmigt es Ihre Ausgaben oder entscheidet, dass eine fehlgeschlagene Prüfung akzeptabel ist. Handlungen mit echten Konsequenzen bleiben für eine Person immer noch stehen, und wir betrachten dies als eine Designentscheidung und nicht als eine Lücke, die es in 3.7 zu schließen gilt.

Es führt auch nicht dazu, dass ein unkontrollierter Einsatz geregelt wird. Die von Ihnen ausgeführte Version ist weit weniger wichtig als die Frage, ob Agenten Eigentümer, Grenzen, Budgets und Kriterien haben. Ein Team mit diesen vier in einer älteren Version ist in einer besseren Verfassung als ein Team ohne sie in dieser Version.

Upgrade

Vorhandene Bereitstellungen werden verschoben, ohne dass Agents neu erstellt werden müssen. Wo Daten Ihre Infrastruktur nicht verlassen können, läuft 3.6 selbst gehostet, in Ihrer eigenen Cloud oder vollständig Air Gap, mit der gleichen Governance.

Als nächstes

Auf der Versionsseite werden alle Versionen ab Keter 1.0 und die jeweils hinzugefügten Elemente aufgeführt. Die Agent Orchestration System-Seiten decken die Betriebsebene ab, die in dieser Version konsolidiert wird.