Copilot harness w Foundry: co przejmuje platforma, co robi zespół

Microsoft 28 października 2026 udostępnił Copilot harness w Foundry Agent Service w public preview. Patrzę na tę zmianę z perspektywy osoby prowadzącej zespół danych: część mechanizmu wykonywania zadań przejmuje platforma. Zespół nadal ustala, jaki raport ma powstać, z jakich danych i kto podpisuje się pod wynikiem. Stan informacji w tym tekście: 30 października 2026.

Weźmy cotygodniowe podsumowanie sprzedaży. Chcesz dostać plik z obliczeniami, wykresem i komentarzem do zmian. Przy ocenie nowego narzędzia od razu pytam, ile pracy zostanie przy przygotowaniu danych i sprawdzaniu odpowiedzi. Ładny pokaz na konferencji trwa kilka minut. Twój poniedziałkowy raport ma jeszcze przeżyć pytania dyrektorki finansowej. Dlatego proponuję przeczytać tę premierę przez pryzmat jednego, mierzalnego pilotażu.

Co Microsoft dodaje do pracy agenta

W głównym komunikacie Microsoftu harness oznacza otoczenie modelu: instrukcje, kontekst, środowisko wykonawcze i kontrolę działań. Firma udostępnia przez Foundry warstwę wywodzącą się z prac zespołu GitHub. Obsługa różnych modeli ma pozwalać dobrać model do zadania bez wymiany całego mechanizmu prowadzącego jego pracę.

Ogłoszenie zespołu Foundry wymienia wielokrotnego użytku procedury, czyli skills, narzędzia Foundry i MCP, pracę z plikami i kodem oraz delegowanie ograniczonych zadań podagentom. Microsoft prowadzi pętlę agenta i sandbox, czyli wydzielone środowisko wykonania. Użytkownik dostarcza wiedzę, procedury i narzędzia. To właśnie ten podział biorę za punkt wyjścia do rozmowy z zespołem.

Przydatność rozwiązania oceniam po tym, którą konkretną pracę zdejmie z naszej listy. Jeżeli programista utrzymuje własny mechanizm przekazywania wyników narzędzi do modelu, zarządzany harness jest tematem do porównania. Jeżeli analityczka potrzebuje raz wyjaśnić formułę w Excelu, zaczynam od prostszego narzędzia. W czwartym tygodniu kursu nazywamy to doborem skali rozwiązania. Nowa premiera daje kolejną opcję w tej decyzji.

Najpierw wybierz raport i jego odbiorcę

W pilotażu wybieram jedno pytanie biznesowe. Na przykład: które kategorie odpowiadają za zmianę sprzedaży względem poprzedniego tygodnia? Ustalam zamknięty okres, słownik kategorii i definicję sprzedaży. Dołączam zatwierdzoną tabelę kontrolną. Tak przygotowane zadanie pozwala ocenić zarówno obliczenia, jak i jakość komentarza, bez otwierania dziesięciu pobocznych dyskusji o danych.

Właścicielem wyniku zostaje konkretna osoba. Analityczka sprawdza zgodność sum i okresów, odbiorca biznesowy ocenia użyteczność komentarza, a osoba techniczna odpowiada za konfigurację wykonania. Jedna osoba może łączyć te role w małej firmie. Nadal zapisuję je oddzielnie, bo „zespół sprawdzi” jest zadziwiająco skutecznym sposobem na pozostawienie zadania bez wykonawcy.

Przed pierwszym uruchomieniem opisuję też granicę publikacji. W tym pilotażu agent przygotowuje szkic do folderu roboczego. Raport wysyła człowiek po odbiorze. Dzięki temu testuję użyteczność analizy w zakresie, który łatwo obejrzeć i poprawić. Ustalenie takiego zakresu rozwijam w tekście o briefie zamiast prompta. Tutaj brief staje się podstawą porównania sposobów wykonania tego samego zadania.

Karta pilotażu do skopiowania

Poniższy szablon jest moją propozycją organizacji pracy. Wklej go do dokumentacji projektu, uzupełnij nawiasy i poproś odbiorcę raportu o zaakceptowanie kryteriów przed konfiguracją agenta. Szczególnie pilnuję ostatnich dwóch pól. To one określają, kiedy kończymy eksperyment i jak wracamy do dotychczasowego procesu.

PILOTAŻ RAPORTU SPRZEDAŻY
Pytanie: które kategorie odpowiadają za zmianę sprzedaży tydzień do tygodnia?
Odbiorca i właściciel decyzji: [imię, rola]
Dane wejściowe: [plik, okres, definicja sprzedaży, słownik kategorii]
Wynik: tabela zmian, wykres, komentarz z odwołaniami do wierszy tabeli.
Zakres agenta: odczyt wskazanych plików, zapis szkicu w folderze roboczym.
Publikacja: po akceptacji przez [imię].
Odbiór: zgodne sumy i okresy, komplet kategorii, każdy wniosek ma dowód.
Przypadek z brakami: agent wskazuje brak i zatrzymuje przygotowanie wniosku.
Pomiar: czas przygotowania, kontroli i poprawek; opłaty za przebieg.
Punkt odniesienia: ten sam raport przygotowany dotychczasową metodą.
Warunek kontynuacji: [próg jakości oraz akceptowalny koszt i czas]
Koniec pilotażu i powrót: [data decyzji, osoba, dotychczasowa procedura]

Przykład celowo kończy się na szkicu raportu. Rozszerzenie o wysyłkę, samodzielne wybieranie źródeł lub zmianę definicji wskaźnika zapisuję jako osobną decyzję po ocenie wyników. W przeciwnym razie po tygodniu sprawdzasz już inne rozwiązanie niż to, na które zespół się umówił. Trudno wtedy uczciwie porównać nakład pracy i zdecydować, czy pilot zasługuje na dalszy czas.

Policz drogę do zaakceptowanego wyniku

Mierzę cały cykl: przygotowanie wejścia, wykonanie zadania, kontrolę, poprawki i publikację. Przy każdym przebiegu zapisuję osobno czas człowieka i czas oczekiwania na narzędzie. Raport gotowy po minucie może nadal wymagać długiego sprawdzania. W mojej tabeli oszczędność pojawia się dopiero wtedy, gdy odbiorca akceptuje wynik przy uzgodnionej jakości.

Na potrzeby porównania wybieram zwykły tydzień, okres z brakującą kategorią i okres z korektą sprzedaży. To propozycja zestawu odbiorowego, który przygotowujesz z własnych danych. Każdy przypadek ma oczekiwany rezultat albo oczekiwane zatrzymanie pracy. Odrębnie notuję błędny rachunek, pominięty rekord oraz interpretację bez pokrycia w tabeli. Dzięki temu wiadomo, co poprawić w procedurze i czy kolejna wersja rozwiązała problem.

Punkt odniesienia przygotowuję na tym samym zestawie wejściowym. Osoba robiąca raport dotychczasową metodą dostaje identyczne pytanie i definicje. Inaczej porównanie miesza zmianę narzędzia ze zmianą trudności zadania. W arkuszu zostawiam też pole na powód odrzucenia wyniku. Samo „niezaakceptowany” niewiele pomaga, gdy po kilku dniach trzeba rozstrzygnąć, czy zawiniła brakująca instrukcja, dane czy sposób wykonania.

W kosztach uwzględniam również pracę nad instrukcjami i poprawkami. Microsoft zapowiada naliczanie opłat za runtime harnessu od 1 grudnia 2026; wcześniejsze zwolnienie dotyczy tej warstwy, a wywołania modeli i osobno rozliczane narzędzia nadal podlegają swoim opłatom. Dlatego do karty pilotażu wpisuję całkowity koszt zaakceptowanego raportu, razem z czasem zespołu. Sam rachunek za model daje zbyt wąski obraz decyzji.

Sprawdź ograniczenia przed planem migracji

W public preview harness wybiera się przy tworzeniu agenta. Dokumentacja Microsoft Learn potwierdza brak przełączania istniejącego agenta oraz brak SLA dla preview; Microsoft odradza użycie produkcyjne tej wersji. Z tego powodu planuję osobny pilotaż i porównuję jego wyniki z obecnym procesem. W harmonogramie zostawiam miejsce na przeniesienie procedury, sprawdzenie dostępu do danych i odbiór wyników.

Zanim zespół zacznie konfigurować środowisko, proszę osobę techniczną o krótkie potwierdzenie dostępności potrzebnego modelu, narzędzi i regionu w wybranej konfiguracji. Do protokołu wpisujemy datę oraz to, co faktycznie wykorzystamy. Pomijam obietnice procentowej oszczędności: opisuję ogłoszoną usługę i plan jej oceny, bez własnego testu Foundry. Wynik pilotażu ma odpowiedzieć na pytanie o korzyść dla konkretnego zespołu.

Osobno sprawdzam możliwość przeniesienia samej wiedzy o zadaniu. Definicję sprzedaży, wzorcowy raport i kryteria akceptacji przechowuję w dokumentacji projektu. Przy ocenie platformy pytam, ile pracy wymaga użycie tych materiałów w innym rozwiązaniu. Ten koszt wpisuję do decyzji obok konfiguracji i utrzymania. Zespół ma zachować kontrolę nad procedurą nawet wtedy, gdy zmieni dostawcę wykonania.

Na spotkaniu kończącym pilot rozdzielam usterki blokujące i kosmetykę. Zła suma albo pominięta kategoria blokuje odbiór. Kolor wykresu trafia na listę poprawek prezentacji. Ustalam tę hierarchię wcześniej, żeby atrakcyjny wygląd raportu nie zagłuszył oceny jego treści. Dla każdego błędu zapisuję właściciela poprawki oraz przypadek, na którym potwierdzimy rozwiązanie. Następna runda ma wtedy jasno określony cel.

Co robię z tą wiadomością w poniedziałek

Na poniedziałkowym spotkaniu proszę o decyzję, czy opisany raport uzasadnia czas osoby technicznej. Do rozmowy przynoszę wypełnioną kartę, przykłady wejścia i termin odbioru. Osoba odpowiedzialna za Foundry dostaje konkretne zadanie do wyceny zamiast polecenia „sprawdź, co potrafi nowy Copilot”.

Po pilotażu podejmuję jedną z trzech decyzji: rozwijamy test i wracamy do wdrożenia po ocenie wersji produkcyjnej, poprawiamy wskazany problem albo zostajemy przy dotychczasowej metodzie. Każdą wiążę z wynikami odbioru. Wybór narzędzia do automatyzacji opisuję też w artykule skrypt czy agent. Nowość Microsoftu dodaje do tego wyboru zarządzaną warstwę wykonania. O jej wartości dla Twojej pracy rozstrzyga raport, który faktycznie da się wykorzystać.