O que é uma agência AI-native?

• Agência AI-native é um termo útil para um modelo operacional, não uma categoria jurídica nem promessa de autonomia total.
• Agents assumem papéis delimitados com instruções, conhecimento, tools e uma persona reconhecível. Personalidade define comunicação, nunca acesso ou autoridade.
• Regras determinísticas, state machines e workflows controlam etapas que precisam ser previsíveis. O modelo entra apenas onde linguagem ou julgamento ajudam.
• Pessoas mantêm responsabilidade por clientes, dinheiro, emprego, orientação regulada, ações irreversíveis e toda aprovação que o sistema não possa assumir com segurança.

Cada camada resolve um trabalho diferente. A combinação delas transforma uma demonstração de IA em um sistema operacional gerenciado.

• docAgents e personasUm papel com nome, instruções, conhecimento, tools, modelo, acesso e canais. A persona controla voz e comportamento, não permissões.
• docSkillsMétodos, checklists, referências e scripts reutilizáveis, empacotados uma vez e anexados onde o mesmo padrão de qualidade se repete.
• linkMCPA camada de conexão que permite a clientes de IA aprovados descobrir tools, resources e prompts permitidos por um endpoint autenticado.
• dataKnowledge e User MemoryAgent Knowledge é compartilhado e controlado pelo autor. User Memory é contexto pessoal deliberado, limitado a um usuário autenticado e um Agent.
• codeWorkflows e state machinesWorkflows do Microsoft Agent Framework orquestram etapas do Agent; estados e triggers explícitos controlam o próximo passo; um Flow separado possui a automação geral.
• dataOrleans e digital twinsAtores virtuais possuem identidade e estado duráveis para Agents, sessões, runs, Tasks e outras entidades. Aqui digital twin é um modelo mental de entidade de software, não uma afirmação sobre Azure Digital Twins.
• docTeams, Goals e TasksUm limite privado de colaboração para membros, Goals e KPIs mensuráveis, Tasks tipadas, arquivos, conhecimento, processos, aprovações, custo, tempo e Agents anexados.
• dataStores e pagamentosUm dono separado do comércio para catálogo, carrinho, checkout, pedidos e obrigações do vendedor, com um Agent existente e autorizado como assistente do comprador.

1. 01
   Goal e Task

   Defina resultado, dono, KPI, prazo, dados permitidos e o ponto exato em que uma pessoa precisa decidir.

2. 02
   Agent e Skill

   Dê ao papel uma persona, conhecimento aprovado, método reutilizável, tools e regras de recusa.

3. 03
   MCP e acesso

   Conecte apenas os sistemas necessários por OAuth ou grant explícito e limitado; conectividade não é permissão.

4. 04
   Workflow e estado

   Use uma state machine, um workflow do Agent ou um Flow para etapas previsíveis, tentativas e aprovações.

5. 05
   Dono durável

   Um grain do Orleans mantém o estado exato de Agent, sessão, run, Team Task ou operação de Store sem depender da memória de um processo.

6. 06
   Evidência e próxima ação

   Registre resultado, ator, revisão, custo, tempo e histórico de aprovações; depois atualize o Goal ou entregue a exceção a uma pessoa.

Um mapa prático das camadas de Agent, MCP, memória, workflow, Team, Task, Store e estado durável necessárias para automatizar trabalho real sem fingir que a empresa funciona sem pessoas.

• Onboarding de clientes: um Agent reúne informação permitida, uma state machine valida etapas obrigatórias e uma Team Task encaminha exceções à pessoa certa.
• Operações de conteúdo: persona de marca, fontes aprovadas, Skills reutilizáveis, artefatos versionados e Tasks de revisão substituem cópias dispersas de prompts.
• Suporte e vendas: User Memory guarda preferências permitidas por Agent, enquanto um assistente de Store lê apenas o catálogo e as commerce tools daquele Store.
• Operações recorrentes: um Flow coordena handoffs determinísticos, agendas, tools externos e runs observáveis; Agents cuidam do trabalho linguístico delimitado.
• Liderança: Goals e KPIs ponderados ligam trabalho a Tasks e execuções de Agents, em vez de contar mensagens de chat como progresso de negócio.
• Entrega multicanal: o mesmo Agent publicado pode atender site, canais compatíveis, ChatGPT Plugin ou connector do Claude quando o cliente e a política de acesso permitem.

• Os caminhos de Agent, Skill, hosted MCP, Knowledge, canais compatíveis, User Memory e state machines existem sob as regras de produto, acesso, provedor e release correspondentes.
• O produto Flow está em Preview; seus gates pendentes de confiabilidade, recovery, agenda e carga não devem ser tratados como já comprovados.
• As camadas avançadas do sistema operacional Team estão implementadas para validação focada de early access, mas o release completo ainda tem gates de evidência live, carga, concorrência e falhas.
• Stores e conectores externos de comércio continuam em Preview e limitados ao vendedor. O vendedor responde por dinheiro, impostos, fulfillment, reembolsos, disputas e obrigações com clientes.

Não comece com uma lista de agentes. Comece com um resultado recorrente que tenha dono, evidência e um ponto seguro de parada.

1. 01
   Nomeie o trabalho recorrente.

   Descreva trigger, resultado esperado, frequência, dono atual, custo da falha e decisão humana.

2. 02
   Separe linguagem de regras.

   Use um Agent onde linguagem e julgamento ajudam; use estados, triggers, validações e Flow onde o caminho precisa ser explícito.

3. 03
   Escolha o dono do produto.

   Escolha Agent, Skill, Flow, Team ou Store conforme quem possui identidade, trabalho, colaboração ou comércio.

4. 04
   Conecte a autoridade mínima.

   Exponha apenas MCP tools e dados necessários, limite a memória, teste OAuth e exija aprovação antes de escritas relevantes.

5. 05
   Meça antes de ampliar.

   Revise qualidade, exceções, tempo, custo, impacto no cliente e progresso do Goal antes de adicionar outro processo ou Agent.