Gemini agent презема цели задачи, но прво стигнува во компаниите

Google Cloud на настанот Gemini at Work 2026 на 8 октомври 2026 го претстави Gemini agent како агент за работа што планира задача, користи вештини и алатки и се поврзува со деловни системи од еден интерфејс. Намерата е корисникот да зададе резултат, а системот да ја изврши работата низ повеќе чекори и да врати готов производ во документ, електронска пошта или програмерска средина. Најавата не потврдува дека секоја деловна сметка веќе има пристап.

Почетното воведување е насочено кон компании; поширокиот пристап за потрошувачите е оставен за подоцна, без објавен датум. Во извештајот на TechCrunch, извршниот директор на Google Cloud, Томас Куријан, ја сумира промената со „objectives, not just instructions“. Тоа е суштинската разлика за деловниот корисник: наместо да побара објаснување како да се подготви преглед, може да му зададе на агентот самиот да ги собере дозволените информации, да изработи нацрт и да го врати за преглед.

Што прави агентот по зададената цел

Обичен разговор со четбот завршува со одговор што човекот понатаму го користи. Gemini agent е опишан како систем што може да продолжи по одговорот: да пронајде релевантни податоци, да одбере вештина за постапката, да повика алатка и да го смести резултатот таму каде што се одвива работата. Вештината е повторно употребливо упатство за повеќечекорна задача; алатката му овозможува да дејствува во поврзана апликација или база на податоци. Таа разлика е важна затоа што квалитетен текст сам по себе не ја ажурира задачата, не создава документ и не остава трага за извршеното дејство.

За подолга работа, агентот може да работи во облакот и по затворањето на уредот, а за сложени задачи може да создава привремени подагенти со посебни улоги. Google ја раздвојува оваа оркестрација од изборот на модел: агентот може да користи модели од семејството Gemini или Claude од Anthropic според потребите на задачата. Корисникот може и сам да избере модел. Ова ја прави одлуката за модел дел од процесот на извршување, без да мора да почне нов разговор за секој чекор.

Како би течела работа меѓу поврзани системи

Замислен пример е мал тим што треба да подготви преглед на состојбата на проект за клиент. Агентот би добил цел да ги собере отворените задачи од Jira, поврзаните разговори од Slack и дозволените датотеки од Google Workspace. Потоа би можел да ги спореди податоците, да издвои прашања без одговор и да создаде нацрт во Docs. Тоа е илустрација на најавените можности, а не објавен тест кај конкретна компанија или ветување дека секоја од тие врски е веднаш овозможена за секој корисник.

Тој процес има различни точки на контрола. Пред читањето стои дозволата за секој извор; при користењето алатка е важно дали таа само чита или може да менува записи; пред испраќање на нацртот до клиент стои одлука на одговорно лице. Ако агентот има пристап само до еден проект, барањето за преглед на тој проект не му дава право да отвори други проекти. Човечкото одобрување на излезна порака е правило што тимот може да го постави за ваков процес, а не универзално задолжителен чекор најавен за секоја задача.

Поврзувањето опфаќа различни видови системи: алатки за соработка како Microsoft 365 и Slack, развојни алатки како Git и Jira, деловни платформи како Salesforce и ServiceNow и извори на податоци како BigQuery. За корисникот, суштината на тој список е дека агентот треба да зачува контекст додека преминува од еден систем во друг. Задача може да се претвори во документ без човекот рачно да ги префрла сите податоци, но дозволите и точноста на нацртот остануваат одделни прашања.

Кој му дозволува да чита и да дејствува

Во техничката објава на Google Cloud се опишани посебен идентитет за агентот, улоги со ограничени дозволи и одобрување на пристапот од администраторите за безбедност. При поврзување со надворешен систем, идентитетот и овластувањата се пренесуваат преку стандарди како OAuth. Ова ѝ овозможува на организацијата да го врзе опсегот на пристап до конкретната работа, наместо агентот да ги наследи сите можности на вработениот што му ја задава целта.

Секое дејство се запишува во ревизиска трага под идентитетот на агентот. За извршување е опишана изолирана средина Agent Sandbox, а Agent Gateway ги применува организациските правила на сообраќајот меѓу агентите и поврзаните системи. Во режимот на член на тим во Google Workspace, агентот добива сопствена сметка, адреса за е-пошта, календар и простор во Drive. Пристапот тогаш следи што му е споделено и во кои групи членува, што му дава на тимот препознатлив начин да ја ограничи неговата работа.

Што го запира трошокот

Контролата на потрошувачката е врзана за проект. Во Cloud Billing Console организацијата може да постави цврста граница за трошокот на агентот во реално време. Се следат употребените токени и трошоците за изолираната средина; кога границата ќе се достигне, агентот на тој проект паузира. Одговорното лице потоа може да одлучи дали ќе ја продолжи работата. Таквата пауза е конкретна точка за човечка одлука дури и кога самиот работен тек има повеќе автоматски чекори.

Изборот на модел и насочувањето на барањата се уште еден дел од сметката. Едноставно барање не мора да го користи истиот модел како задача што бара посложено расудување, а една долга задача може да вклучи повеќе различни чекори. Затоа трошокот на готов извештај не може да се прочита од една општа цена: зависи од моделите, траењето, бројот на повици и употребата на изолираната средина. Лимитот по проект му овозможува на тимот да го врзе ризикот за потрошувачка со конкретна работа или оддел.

Кому му е наменето почетното воведување

Деловниот почеток одговара на средина во која веќе постојат администратори, правила за споделување и буџети по проект. Брендот On тестирал динамички избор на модел; тоа е потесен факт од тврдење дека сите функции на новиот агент се пуштени кај сите клиенти. И постојните примери на компании што користат Gemini Enterprise не значат автоматски пристап до секоја новонајавена можност на Gemini agent.

За тим во Северна Македонија, најавата затоа отвора конкретно прашање за достапноста на неговата сметка, покрај прашањата за дозволи и буџет. Следната пресудна информација ќе бидат објавените услови за деловен пристап и распоредот за потрошувачкото пуштање; без нив, претставувањето на агентот не е исто што и општа достапност.

Прочитајте и:

• Gemini 4 Argon пристигна, но пристапот почнува со мала група
• Copilot или Gemini за работа: вклучениот AI не значи иста вредност
• AWS Well-Architected Agent предлага поправки, но пристапот почнува од Business+