DI Core prowadzi od celu do wyniku.

Profil pracy to zestaw ustawień, z jakimi DI Core, silnik AI w DI Cloud, uruchamia pojedyncze zapytanie: jak szeroki kontekst wolno objąć, jak głęboko rozłożyć zadanie, ile wywołań narzędzi dopuścić, jak surowo ocenić gotową odpowiedź, czy sięgnąć do pamięci projektu i czy wolno dopisać zadania do kolejki wykonawczej. Widocznych profili jest dziewięć: od ścieżki konwersacyjnej, przez warianty przygotowane do dokumentów, do kodu i do pracy na źródłach, po tryb wieloetapowy oraz tryb, w którym nad jednym wynikiem pracuje pięć ról — planista, wykonawca, krytyk, weryfikator i redaktor scalający. Wybór profilu należy do użytkownika i wynika z celu, jakiemu ma służyć odpowiedź. Przy ustawieniu automatycznym decyduje router: bierze pod uwagę długość zapytania, obecność załączników, sygnały pracy z kodem oraz sygnały ryzyka operacyjnego. Na ścieżkę najszybszą schodzi zapytanie krótsze niż czterdzieści słów, o ile nie ma przy nim załączników, nie widać sygnałów kodu ani ryzyka i nie pracuje tryb agentowy; samo odwołanie do źródeł tej ścieżki nie wyklucza. Pytanie o obliczenie specjalistyczne jest z niej wyjęte osobną regułą, ponieważ długość tekstu nie jest miarą trudności. Profilu wskazanego ręcznie nie podmienia ranking adaptacyjny, który przy ustawieniu automatycznym premiuje warianty o szerszym kontekście wtedy, gdy zapas kontekstu jest pod presją. Profile głębokie wymagają planu, który je otwiera — bez tego uprawnienia uruchomienie schodzi do wariantu standardowego, a dopuszczalna liczba wywołań narzędzi jest niższą z dwóch wartości: limitu profilu i limitu wdrożenia.

Droga od surowej odpowiedzi modelu do wyniku widocznego w rozmowie prowadzi przez kilka rozdzielonych kroków. Osobne wywołanie ocenia jakość treści, a bezpośrednio po nim sprawdzane są testy akceptacyjne wypisane w planie pracy ułożonym jeszcze przed generowaniem. Jeżeli profil dopuszcza przebieg naprawczy, a ocena albo testy wykazały braki, wynik powstaje po raz drugi i przechodzi obie kontrole ponownie. Dopiero na tym etapie powstaje tablica jedenastu bramek: treść zapytania, strategia odpowiedzi, limit kosztu, trasa dostawcy, zapas kontekstu, wykonanie narzędzi, domknięcie przebiegu, ocena jakości, testy akceptacyjne, a w trybach wykonawczych także wartość wyniku i to, czy odpowiedź trafiła do przestrzeni roboczej. Stan przebiegu wynika ze średniej bramek policzonych, z liczby bramek nieprzeszłych oraz z tego, czy nie zawiodła żadna z bramek uznanych za krytyczne; próg przyjęcia jest wyższy dla profili wykonawczych niż dla pozostałych. Stany są cztery: przyjęty, do przeglądu, zablokowany oraz podglądowy, zarezerwowany dla przebiegu, który nie doszedł do pełnego uruchomienia. Przy zwykłej rozmowie dwie ostatnie bramki zostają pominięte i nie wchodzą do średniej, ponieważ odpowiedź konwersacyjna nie ma obowiązku zostawić po sobie dokumentu ani zadania.

Odpowiedzi w rozmowie DI Cloud towarzyszy plakietka werdyktu: nazwa poziomu zaufania w skali czterostopniowej, dwie wartości od zera do stu — pewność wyprowadzona z oceny treści i jakość wyprowadzona z tablicy bramek — liczba przywołanych źródeł oraz licznik sygnałów pozostawionych pod obserwacją. Po rozwinięciu widać powody, rozdzielone na mocne strony przebiegu i zastrzeżenia. Na liście źródeł zostają wyłącznie te, do których odpowiedź odwołała się znacznikiem w swojej treści, najwyżej osiem pozycji, a ich kolejność odpowiada pierwszemu wystąpieniu znacznika, nie kolejności wyszukiwania; ten sam filtr obejmuje fragmenty dokumentów projektu i materiały zebrane w sieci. Wyszukiwanie po dokumentach zwraca najbliższe fragmenty także przy pytaniu z nimi niezwiązanym, więc obecność pliku w projekcie nie dowodzi, że został użyty. Gdy źródeł nie ma, a odpowiedź przekracza próg długości albo zawiera liczby, plakietka pokazuje oznaczenie „Bez źródeł”, poziom zaufania spada o stopień, a pewność o dwanaście punktów; wartość jakości pozostaje bez zmian, ponieważ opisuje przebieg, a nie pochodzenie treści. W osobnym trybie pytań do dokumentów projektu brak dopasowania zostaje oznaczony wprost jako niedostateczne źródła, a pewność jest tam wartością słowną — niską, średnią albo wysoką — nie liczbą.

Rola silnika kończy się na przygotowaniu wyniku i opisaniu, na czym ten wynik stoi. DI Core nie rozstrzyga za użytkownika i nie jest zbiorem faktów o gwarantowanej poprawności: bramki mierzą przebieg — długość i kompletność zapytania, obecność strategii, mieszczenie się w limicie kosztu, zachowanie dostawcy, zapas kontekstu, liczbę wykonanych narzędzi — a nie zgodność każdego zdania z rzeczywistością. Wysoka pewność opisuje zatem warunki uruchomienia, nie prawdziwość pojedynczego twierdzenia, a odnośnik do materiału jest podany po to, aby dało się go otworzyć. Sama plakietka nie zleca oceny drugiemu modelowi; korzysta z wartości policzonych w tym samym przebiegu. Nie każde uruchomienie kończy się zresztą wywołaniem modelu: gdy odpowiedź na pytanie o załącznik da się wskazać wprost w jego treści, przebieg zamyka się na odczycie, a w pokwitowaniu zostaje zapis, że dostawcy nie wywołano. Przełączenie na kolejny dostępny model następuje wyłącznie wtedy, gdy dostawca zawiedzie przed wysłaniem pierwszego fragmentu odpowiedzi; po tym momencie przebieg nie jest zaczynany od nowa na innym modelu, żeby użytkownik nie otrzymał dwóch sklejonych początków, a jedna tura nie naliczyła się dwukrotnie. Nie ma więc obietnicy, że dwa uruchomienia tego samego zapytania pójdą tą samą trasą.