Agent-Native + Claude Code: finalmente, apps em que seu agent de IA pode realmente trabalhar (open source)

Ver no idioma original →

Autoria: AICodeKing · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Agent-Native + Claude Code: Finally! Apps Your AI Agent Can Actually Work In (Open Source) · Canal: AICodeKing · 14:01 · Assistir no YouTube

Tópicos: Agentes de IA, Claude Code, Engenharia de software com IA, Geração de conteúdo com IA

Resumo

O vídeo apresenta o Agent Native, um framework open source da Builder para criar agents com interfaces interativas, usando como exemplo o app Slides. O apresentador demonstra como gerar uma apresentação, editar manualmente textos e a ordem dos slides e pedir ao agent que continue a partir da versão atualizada. Em seguida, explica como iniciar um projeto e como ações compartilhadas e o contexto da interface conectam o agent aos dados do app. Por fim, mostra como personalizar o projeto com Claude Code ou Codex e destaca limitações, incluindo o estado alpha dos apps e a necessidade de avaliar as alterações.

Pontos-chave

• O Agent Native permite criar agents com interfaces interativas em React, usando um modelo próprio e mantendo o código no próprio repo.
• No app Slides, é possível gerar uma apresentação e depois editar manualmente textos e a ordem dos slides.
• O agent pode continuar o trabalho com base nas alterações feitas na interface, desde que receba o contexto adequado.
• A opção de revisar um trecho selecionado permite direcionar uma solicitação de edição a um texto específico.
• Ações compartilhadas podem ser usadas tanto pela interface quanto pelo agent, com validações mantidas em um só lugar.
• O contexto da interface pode informar ao agent qual documento, slide ou seleção está em foco.
• O projeto de exemplo pode ser iniciado localmente com Node 22.22 ou posterior e PNPM; o uso do modelo e da infraestrutura pode ter custos.
• Os apps de exemplo estão marcados como alpha, e conectar um agent a um editor não garante que todas as alterações sejam boas.

Capítulos

Início	Capítulo	Resumo
00:02	Apresentação do Agent Native e edição manual	O vídeo introduz o fluxo de editar uma apresentação diretamente na interface e apresenta o Agent Native e o app Slides.
02:38	Criar, editar e revisar uma apresentação	O apresentador gera uma apresentação, altera o texto e a ordem dos slides e pede ao agent uma revisão direcionada.
06:45	Iniciar o projeto e entender as ações	O vídeo explica como rodar o projeto localmente e apresenta ações compartilhadas para ler e modificar dados da apresentação.
09:23	Contexto da interface e personalização	O apresentador explica como fornecer ao agent o contexto do documento e da seleção e sugere testar um workflow pequeno.
12:29	Limitações e avaliação do workflow	O vídeo aborda a personalização com coding agents, as limitações dos apps alpha e os casos em que interfaces interativas podem ser úteis.

Citações

Às vezes, você só quer clicar no texto e corrigir por conta própria. — 00:02

Mudamos tanto o texto quanto a ordem pela interface. — 04:11

Como desenvolvedor, você precisa conectar o contexto que importa para o seu app. — 09:55

Conectar um agent a um editor não garante que todas as alterações serão boas. — 12:59

Conceitos e entidades

• Agent Native (ferramenta): Framework TypeScript open source da Builder para criar agents com interfaces interativas.
• Builder (empresa): Empresa que desenvolveu o Agent Native.
• Slides (ferramenta): App de apresentações usado no vídeo para demonstrar edição manual e interação com um agent.
• React (ferramenta): Biblioteca que pode ser usada para construir a interface de um app com Agent Native.
• OpenRouter (ferramenta): Provedor conectado para o modelo usado na demonstração.
• Ollama (ferramenta): Opção de modelo local mencionada no processo de configuração do projeto.
• Claude Code (ferramenta): Coding agent citado como opção para personalizar o código do app gerado.
• Codex (ferramenta): Coding agent citado como opção para personalizar o código do app gerado.
• MCP (conceito): Uma das formas mencionadas de disponibilizar ações do app para o agent.

Tradução completa (pt-BR)

00:02 Olá. Bem-vindos a mais um vídeo. Digamos que você peça a um agent de IA para criar uma apresentação. Ele entrega um rascunho, mas você quer mudar um título, mover um slide e deixar uma seção mais técnica. Essas são coisas bem normais de fazer quando se está trabalhando em uma apresentação. Você poderia continuar descrevendo cada pequena mudança no chat, mas às vezes só quer clicar no texto e corrigir por conta própria. E, quando voltar ao agent, vai querer que ele entenda a apresentação como ela está agora, incluindo as mudanças que você acabou de fazer. É isso que vamos explorar hoje

00:33 com o Agent Native, um framework TypeScript open source da Builder para criar agents com interfaces interativas. Você pode usar React, trazer seu próprio modelo, manter o código da aplicação no seu próprio repo e fazer deploy em um host compatível à sua escolha. Vamos conhecer o app Slides, criar uma apresentação pequena, editá-la manualmente e, depois, pedir ao agent que continue a partir da versão atualizada. Depois disso, vou mostrar como começar sua própria cópia e onde as actions e o contexto da aplicação se encaixam no código. Então, vamos começar. Primeiro, abra

01:04 o site do Agent Native, vá até Slides e clique em Create a Deck. Depois de entrar, talvez apareça uma pergunta opcional sobre sua função. Você pode responder ou escolher Skip for now. Em seguida, vem a configuração do modelo. A tela oferece usebuilder.io, ou você pode ignorar essa opção e configurar seu próprio provedor. Entrar na conta e conectar um modelo são etapas separadas, então confira isso antes de tentar gerar qualquer coisa. Neste passo a passo, o provedor conectado é o Open Router, em Model Settings. Confira também se há um modelo padrão selecionado. Se o campo de composição ainda disser Connect Agent ou Connect Keys, volte e confira a conexão

01:36 e as configurações do modelo antes de enviar um prompt. Agora, esta é a tela inicial. Você pode descrever uma apresentação diretamente na caixa grande de prompt. Há também um menu de importação com opções para PDF, Google Slides e PPT. E, abaixo, você pode explorar templates. Vamos dar uma olhada rápida em um deles primeiro. Ao abrir Launch Keynote, temos uma apresentação com sete slides. Estou dando a ela o nome de demonstração do passo a passo do AI Code King, para ser fácil encontrá-la novamente. No primeiro slide, o título diz “conheça Lumen”. Clique duas vezes no título para abrir um editor de texto com controles de formatação. Vou substituir esse título por

02:08 Agent UI. A versão mais longa que experimentei ultrapassou os limites do layout fixo deste template, então é importante ficar de olho na tela. Aqui está o título atualizado, e ele continua lá quando reabro a apresentação. Também posso arrastar uma miniatura na faixa de slides para mover um slide. Por exemplo, coloquei o slide das três ideias antes do slide de exemplo de benchmark. Então, você pode começar com um layout existente e fazer edições manuais comuns antes de envolver o agent. Ainda é preciso substituir os números de exemplo e o texto provisório para transformar isso em uma apresentação de verdade. Quando houver um modelo disponível,

02:38 vamos voltar às apresentações e usar a caixa de prompt para criar nosso próprio exemplo. Quero fazer uma apresentação curta para desenvolvedores sobre como adicionar um agent de IA a um workflow de conteúdo. Assim, temos algo específico com que trabalhar, e podemos manter o exemplo pequeno o bastante para analisá-lo direito. Vou dar a ele este prompt: “Crie uma apresentação de seis slides para desenvolvedores React sobre como criar um assistente de conteúdo com IA. Aborde o problema, um workflow proposto, actions compartilhadas, revisão humana, um exemplo prático e uma conclusão. Use títulos curtos, fundo escuro e uma cor de destaque. Mantenha

03:10 a linguagem prática e não invente estatísticas.” Vamos enviar e ver o resultado. Enquanto a apresentação é criada, observe o editor. O workflow documentado adiciona os slides à apresentação à medida que o agent os cria, para que você possa acompanhar o trabalho no próprio app. Quando a geração terminar, vamos percorrer os slides. Vou verificar se ele seguiu o roteiro, se o texto cabe e se a explicação faria sentido para alguém que nunca usou esse framework. É aqui que eu dedicaria um tempo antes de pedir mais mudanças. Um slide pode parecer bem acabado e ainda assim ter uma explicação

03:40 fraca. Por exemplo, se o slide sobre actions compartilhadas apenas disser que tudo está conectado, eu iria querer um exemplo concreto do que está sendo conectado. Agora, vamos fazer uma mudança por conta própria. Abra o slide sobre revisão humana, clique duas vezes no título e substitua-o por “sempre revise antes de publicar”. Escolhi essa formulação porque quero deixar clara a posição defendida nesta apresentação. O agent pode ajudar a preparar o trabalho, mas a pessoa que usa o app deve poder analisá-lo e decidir quando está pronto. Em seguida, arraste esse slide na faixa de slides para que ele fique logo depois do workflow proposto. Isso coloca a etapa de revisão

04:11 mais cedo na narrativa, antes de entrarmos nos detalhes da implementação. Então, mudamos tanto a redação quanto a ordem pela interface. Deixe essas edições serem salvas antes de continuar. Agora, mantenha aberto o slide de revisão e volte ao agent. Aqui está o próximo prompt: “Deixe este slide mais técnico para um desenvolvedor React. Mantenha exatamente como está o título que acabei de editar. Substitua o corpo por três pontos concisos sobre validar entradas, verificar permissões e revisar um rascunho antes de publicar. Não altere os outros slides.” Repare que estou me referindo a este slide.

04:42 Também estou me referindo ao título que alterei manualmente, sem colá-lo de volta na conversa. Vamos enviar e conferir o resultado. Há pontos bem específicos a verificar: ele editou o slide que está aberto no momento? Preservou o novo título? E o slide permaneceu na posição em que o colocamos? Esses detalhes importam porque nos dizem se o agent está trabalhando com o estado atual da aplicação. Se ele trouxer de volta o título antigo ou mudar outro slide, precisamos corrigir isso antes de continuar. Para fazer uma edição ainda mais direcionada, selecione uma frase no slide e

05:13 escolha revise with AI no menu flutuante. Isso abre uma pequena caixa de prompt que mostra o texto selecionado, com um botão para enviar ao agent. Peça que ele explique essa frase usando um exemplo de aprovação de conteúdo, com no máximo 20 palavras, e envie a solicitação. Essa seleção dá um alvo claro à solicitação. Quando digo “deixe isto mais claro”, o app tem como indicar ao agent a que trecho de texto estou me referindo. Acho que essa é uma interação útil para o trabalho cotidiano. Você pode delegar um rascunho maior, fazer diretamente uma pequena mudança na redação e depois devolver uma parte específica

05:44 ao agent. Você decide de quanta ajuda precisa em cada etapa. Agora, vamos usar a mesma apresentação para mais um refinamento. Abra o slide do exemplo prático e peça ao agent que descreva um workflow em que ele cria um rascunho de descrição para um vídeo, o criador o edita e, depois, o agent encurta essa versão editada, preservando, sempre que possível, as palavras do criador. Estou mantendo este exemplo próximo de algo que eu realmente gostaria de ter em uma ferramenta de conteúdo. Às vezes, uma frase está tecnicamente correta, mas não soa como você. Poder editar essa frase por conta própria é valioso. Quando a revisão

06:14 estiver pronta, leia o texto no slide. Confira se ele descreve um rascunho e uma etapa de revisão e se não transformou discretamente nosso exemplo em publicação automática. Depois, clique em apresentar e percorra a apresentação desde o início. Confira a nova ordem dos slides, o título que mudamos e a explicação técnica. Também é uma boa hora para perceber se o texto está pequeno demais ou se algum slide ficou cheio demais. Se quiser levar a apresentação para outro editor, abra o menu de mais opções, indicado por três pontos, e escolha exportar. O menu oferece baixar como HTML, exportar como

06:45 PDF, exportar como PPTX e exportar para Google Slides. Mesmo assim, eu conferiria qualquer arquivo exportado, porque fontes e layouts podem ser exibidos de maneira diferente em cada editor. Enfim, agora vamos ver como você pode executar e personalizar isso por conta própria. Você vai precisar do Node versão 22.22 ou posterior e do PNPM. Abra o terminal na pasta onde guarda seus projetos. Para o projeto inicial de slides, execute npx --yes @agent-native/core@latest create-my-slides --standalone --template slides. Vou colocar o comando exato

07:17 na descrição para você poder copiá-lo. Em seguida, execute cd my-slides. Se o PNPM não estiver disponível, o guia de introdução usa corepack enable. Execute pnpm install e depois pnpm dev. Abra o endereço local exibido no terminal. O processo de configuração local oferece a opção continue as local dev; depois, você precisará conectar um modelo. As opções documentadas incluem Builder, a conexão com seu próprio provedor ou um modelo local do Ollama. O framework em si é gratuito e open source. O uso do modelo e a infraestrutura que você escolher ainda podem ter custos. A configuração da Builder também oferece créditos gratuitos,

07:49 mas confira a franquia disponível ao entrar. Para este primeiro experimento, eu usaria uma apresentação pequena e evitaria gerar imagens desnecessárias. Assim, fica mais fácil se concentrar no fluxo de edição e entender quanto você está gastando. Agora, abra o projeto gerado no seu editor de código. Vamos consultar o guia para desenvolvedores do Slides junto com ele. Começando pela ação simplificada de atualização de slides. O exemplo usa uma função chamada define action. A descrição dela explica a operação, o esquema define as entradas e a função run contém o código que realiza a edição. Para atualizar um slide,

08:20 essas entradas incluem o ID da apresentação e o ID do slide, além de uma substituição direcionada ou do novo conteúdo do slide. O exemplo verifica o acesso do editor antes de alterar a apresentação e notifica os clientes conectados depois de salvar. Assim, o agent recebe uma operação definida que pode chamar em uma apresentação real. Você pode inspecionar essa operação, mudar o comportamento dela e decidir o que ela pode fazer. No framework, o React pode chamar ações por meio de hooks, como use action query para leituras e use action mutation para alterações. Essas ações também podem ser disponibilizadas pelo agent HTTP e pelo MCP. Para o seu

08:53 próprio app, imagine uma ação de renomear rascunho. Um campo de texto na interface poderia chamá-la quando o usuário salvasse o título. O agent poderia chamá-la quando o usuário pedisse um título diferente. Você mantém a lógica de validação e renomeação nessa ação compartilhada. Isso também daria a você um único lugar para impor uma regra, como rejeitar um título vazio. Se depois você mudar a regra, os dois chamadores poderão usar o comportamento atualizado. Mas há um detalhe útil na implementação do Slides. O editor no navegador envia operações de edição granulares por meio de uma ação patch deck, enquanto o agent também tem ações dedicadas, como

09:23 update slide. Essas operações compartilham o mesmo mecanismo subjacente de apresentação e bloqueio. Então, ao inspecionar o código-fonte, veja como as operações de fato se conectam. Controles de edição diferentes podem precisar de entradas diferentes e ainda assim operar sobre os mesmos dados do app. Agora, a próxima pergunta é como o agent sabe o que esse slide significa. Abra a documentação sobre consciência de contexto. A interface fornece informações como a visualização atual e a seleção. E uma ação view screen pode usar essas informações para buscar os registros relevantes. Em uma apresentação, esse contexto pode

09:55 identificar a apresentação em que você está trabalhando e o slide ou elemento selecionado. Em um editor de conteúdo, você poderia fornecer o rascunho atual e o parágrafo que está sendo editado. Como desenvolvedor, você precisa conectar o contexto relevante para o seu app. Eu começaria com alguns IDs úteis e a seleção atual, e depois garantiria que o agent pudesse recuperar o conteúdo correspondente. Por exemplo, se alguém selecionar a descrição de um vídeo e pedir para encurtá-la, quero que o pedido esteja vinculado ao rascunho selecionado. Seria frustrante o agent ter que adivinhar entre vários documentos com nomes parecidos. Você pode

10:25 verificar esse comportamento diretamente durante o desenvolvimento. Abra um rascunho, faça uma alteração manual e peça ao agent para resumir a versão atual. Depois, mude para outro rascunho e repita o pedido. A resposta deve acompanhar o objeto que você realmente abriu. Isso oferece uma forma prática de avaliar a camada de contexto antes de criar um fluxo de trabalho muito maior em torno dela. O framework também oferece suporte a dados de back-end compartilhados do banco de dados. Isso permite que a interface e o agent trabalhem com os mesmos registros armazenados, enquanto o estado do app descreve coisas como a seleção atual. Essas duas partes

10:56 têm funções diferentes e ambas são úteis nesse tipo de editor. Pessoalmente, eu começaria personalizando um único fluxo de trabalho em um dos exemplos. Para apresentações, poderia ser um formato de apresentação repetível para o seu canal. Para um app de conteúdo, poderia ser redigir e revisar descrições. Escolha uma operação que você possa realizar tanto manualmente quanto pelo agent. Depois, veja o que acontece quando alterna entre os dois. O agent preserva a edição humana? A interface mostra o resultado mais recente? Você consegue recuperar o trabalho se a revisão

11:26 seguir na direção errada? Esses são os detalhes que eu acertaria antes de adicionar mais recursos. E, como você tem o código-fonte, também pode usar algo como Claude Code ou Codex para personalizar o próprio app. É aí que fica bem interessante. Abra a pasta do projeto gerado no seu agent de programação e peça primeiro que ele inspecione a estrutura existente; depois, descreva em linguagem comum a alteração que você quer. Por exemplo, eu poderia dizer: “Adicione uma lista de verificação de revisão a cada apresentação. Permita que eu marque o conteúdo, o design e a precisão técnica como revisados pela

11:57 interface. Salve essas escolhas junto com a apresentação e permita que o agent integrado leia e atualize a mesma lista de verificação por meio de ações compartilhadas. Siga os padrões existentes neste projeto.” Assim, estamos dando ao agent de programação um recurso específico para implementar, incluindo como ele deve funcionar tanto para a pessoa que usa a interface quanto para o agent dentro do app. Depois que ele fizer as alterações, execute o app localmente e confira o resultado. Marque um item você mesmo e, em seguida, pergunte ao agent integrado quais verificações ainda estão incompletas. Isso oferece uma forma simples de ver se os dois lados estão trabalhando com as mesmas informações salvas, e você pode continuar

12:29 aprimorando. Mova a lista de verificação para perto da prévia do slide, deixe-a mais compacta ou adicione um status de revisão à lista de apresentações. Descreva o que você quer, inspecione as alterações e teste o fluxo de trabalho novamente. Pessoalmente, acho que isso torna a parte open source muito mais útil. Você tem um app existente como ponto de partida, e um agent de programação pode ajudar a adaptá-lo à maneira como você realmente trabalha. Agora, há algumas limitações que vale ter em mente. Os apps de exemplo estão marcados como alpha, e conectar um agent a um editor não garante que todas as edições serão boas. Você ainda precisará

12:59 avaliar o modelo, os prompts e a maneira como suas ações lidam com as alterações. E, se todo o seu caso de uso for fazer uma pergunta e ler uma resposta curta, uma interface de chat simples talvez já resolva. Acho que essa abordagem se torna mais útil quando as pessoas precisam navegar, selecionar, editar e revisar o trabalho em várias etapas. Uma apresentação é um bom exemplo porque a ordem, o layout e a formulação exata importam. Um calendário de conteúdo ou um editor de documentos poderia se beneficiar por motivos semelhantes. O que eu gosto nessa arquitetura é que ela oferece pontos concretos para trabalhar nessas interações.

13:30 Você tem ações do app para inspecionar, dados para atualizar e contexto para transmitir pela interface. Isso torna o fluxo de trabalho algo que você pode criar e avaliar passo a passo. Então, se quiser experimentar, acesse o site Agent Native pelo link na descrição. Comece com um app existente, faça algo pequeno, edite você mesmo e peça ao agent para continuar. Depois, abra o código-fonte e personalize a parte que o tornaria útil para o seu próprio fluxo de trabalho. No geral, é bem legal. Enfim, me conte o que você achou nos comentários. Se gostou deste vídeo, considere fazer uma doação pela opção Super Thanks ou se tornar membro

14:01 clicando no botão Join. Além disso, deixe seu gostei neste vídeo e inscreva-se no meu canal. Vejo você no próximo. Até lá, tchau.

Transcrição original

[00:02] Hi. Welcome to another video. So, let’s say you ask an AI agent to create a presentation. It gives you a draft, but you want to change a heading, move a slide, and make one section more technical. Those are pretty normal things to do when you’re working on a presentation. Now, you could keep describing every little change in chat, but sometimes you just want to click the text and fix it yourself. And when you go back to the agent, you want it to understand the presentation as it exists now, including the changes you just made. That’s what we’re going to explore today

[00:33] with Agent Native, an open-source TypeScript framework from Builder, for building agents with interactive interfaces. You can use React, bring your own model, keep the application code in your own repository, and deploy on a supported host of your choice. We’re going to walk through their Slides app, create a small presentation, manually edit it, and then ask the agent to continue from that updated version. After that, I’ll show you how to start your own copy and where the actions and application context fit into the code. So, let’s get right into it. First, open

[01:04] the Agent Native website, go to Slides, and click Create a Deck. Once you’re signed in, you may get an optional question about your role. You can answer it or choose Skip for now. Next comes the model setup. The screen offers usebuilder.io, or you can skip that option and configure your own provider. Signing in and connecting a model are separate steps, so check this before you try to generate anything. For this walk-through, the connected provider is Open Router in Model Settings. Also, check that a default model has been selected. If the composer still says Connect Agent or Connect Keys, go back and check the connection

[01:36] and model settings before sending a prompt. Now, this is the home screen. You can describe a presentation directly in the large prompt box. There’s also an import menu with PDF, Google Slides, and PPT options. And below that, you can browse templates. Let’s take a quick look at one of those first. Opening Launch Keynote gives us a seven-slide deck. I’m naming this AI Code King walkthrough demo, so it’s easy to find again. On its first slide, the heading says meet Lumen. Double-click the heading and you get a text editor with formatting controls. I’m replacing that title with

[02:08] Agent UI. The longer wording I tried overflowed this template’s fixed layout, so keeping an eye on the canvas matters. There’s the updated title, and it stays there when I reopen the deck. I can also drag a thumbnail in the filmstrip to move a slide. For example, I moved the three ideas slide ahead of the sample benchmark slide. So, you can start from an existing layout and make ordinary manual edits before involving the agent. The sample numbers and placeholder copy still need replacing before this could become a real presentation. Once a model is available,

[02:38] let’s go back to decks and use the prompt box for our own example. Now, I want to make a short presentation for developers about adding an AI agent to a content workflow. This gives us something specific to work with, and we can keep the example small enough to inspect properly. I’m going to give it this prompt. Create a six-slide presentation for React developers about building an AI content assistant. Cover the problem, a proposed workflow, shared actions, human review, a practical example, and a closing takeaway. Use short headings, a dark background, and one accent color. Keep

[03:10] the language practical and do not invent statistics. Let’s send it and see. As the deck builds, watch the editor. The documented workflow brings slides into the presentation as the agent creates them, so you can follow the work in the app itself. Once generation finishes, let’s click through the slides. I’m looking at whether it followed the outline, whether the text fits, and whether the explanation would make sense to somebody who hasn’t used this framework before. This is where I’d spend a little time before asking for more changes. A slide can look polished and still have a weak

[03:40] explanation. For example, if the shared action slide just says that everything is connected, I’d want an actual example of what gets connected. Now, let’s make a change ourselves. Open the human review slide, double-click its heading, and replace it with always review before publishing. I’m choosing that wording because I want a clear point of view in this presentation. The agent can help prepare the work, but the person using the app should be able to inspect it and decide when it’s ready. Next, drag that slide in the filmstrip so it comes immediately after the proposed workflow. That puts the review

[04:11] step earlier in the story before we get into the implementation details. So, we’ve changed both the wording and the order through the interface. Let those edits save before continuing. Now, keep the review slide open and go back to the agent. Here’s the next prompt. Make this slide more technical for a React developer. Keep the heading I just edited exactly as it is. Replace the body with three concise points about validating inputs, checking permissions, and reviewing a draft before publishing. Leave the other slides unchanged. Notice that I’m referring to this slide.

[04:42] I’m also referring to the heading I changed manually without pasting that heading back into the conversation. Let’s send it and check the result. The things to check here are very specific. Did it edit the slide that’s currently open? Did it preserve the new heading? And did the slide stay in the position where we put it? Those details matter because they tell us whether the agent is working with the current application. If it brings back the old heading or changes a different slide, that’s something we need to correct before moving on. For an even more targeted edit, select a sentence in the slide and

[05:13] choose revise with AI from the bubble menu. That opens a small prompt box showing the selected text with a sent agent button. Ask it to explain that sentence using a content approval example in no more than 20 words, then send the request. That selection gives the request a clear target. When I say make this clearer, the app has a way to tell the agent which piece of text I’m talking about. I think this is a useful interaction for everyday work. You can delegate a larger draft, handle a small wording change directly, and then hand a specific part

[05:44] back to the agent. You decide how much help you need at each point. Now, let’s use the same deck for one more refinement. Open the practical example slide and ask the agent to describe a workflow where it drafts a video description, the creator edits it, and the agent then shortens that edited version while preserving the creator’s wording where possible. I’m keeping this example close to something I would actually want from a content tool. There are times when a sentence is technically fine, but it doesn’t sound like you. Being able to edit that sentence yourself is valuable. Once the revision

[06:14] is ready, read it on the slide. Check that it describes a draft and a review step, and that it hasn’t quietly turned our example into automatic publishing. Then click present and go through the deck from the beginning. Check the new slide order, the heading we changed, and the technical explanation. This is also a good time to catch text that’s too small, or a slide that has become too crowded. If you want to take the presentation into another editor, open the three-dot more menu, and then export. The menu has download as HTML, export as

[06:45] PDF, export as PPTX, and export to Google Slides. I’d still check any exported file because fonts and layouts can render differently between editors. Anyway, now let’s look at how you can run and customize this yourself. You’ll need Node version 22.22 or later, and PNPM. Open your terminal in the folder where you keep your projects. For the slide starter, run NPX {dash} {dash} yes at agent-native/core at latest. create-my-dash-slides {dash} {dash} standalone {dash} {dash} template slides. I’ll put the exact command in

[07:17] the description so you can copy it. Then run CD my-dash-slides. If PNPM isn’t available, the getting started guide uses corepack enable. Run PNPM install followed by PNPM dev. Open the local address printed in your terminal. The local onboarding offers continue as local dev, and you’ll then need to connect a model. The documented choices include builder, your own provider connection, or a local Ollama model. The framework itself is free and open source. Model usage and the infrastructure you choose can still have costs. Builders setup also offers free credits,

[07:49] but check the allowance available when you sign in. For this first experiment, I’d use a small deck and avoid generating unnecessary images. That makes it easier to concentrate on the editing workflow and understand what you’re spending. Now, open the generated project in your code editor. Let’s look at the Slides developer guide alongside it. Starting with the simplified update slide action. The example uses a function called define action. Its description explains the operation, its schema defines the inputs, and its run function contains the code that performs the edit. For a slide update,

[08:20] those inputs include the deck ID and slide ID, along with either a targeted replacement or new slide content. The example checks editor access before changing the deck and notifies connected clients after saving. So, this gives the agent a defined operation it can call against a real presentation. You can inspect that operation, change its behavior, and decide what it is allowed to do. Across the framework, React can call actions through hooks, such as use action query for reads, and use action mutation for changes. Those actions can also be made available through the agent HTTP and MCP. For your

[08:53] own app, imagine a rename draft action. A text field in the interface could call it when the user saves the title. The agent could call it when the user asks for a different title. You maintain the validation and rename logic in that shared action. That would also give you one place to enforce a rule such as rejecting an empty title. If you later change the rule, both callers can use the updated behavior. There’s a useful implementation detail in Slides though. Its browser editor sends granular editing operations through a patch deck action, while the agent also has dedicated actions such as

[09:23] update slide. These operations share the same underlying deck and locking mechanism. So, when you’re inspecting the source, look at how the actual operations connect. Different editing controls can need different inputs while still working against the same application data. Now, the next question is how the agent knows what this slide means. Open the context awareness documentation. The interface supplies information such as the current view and selection. And a view screen action can use that information to fetch the relevant records. In a presentation, that context can

[09:55] identify the deck you’re working on and the slide or element you’ve selected. In a content editor, you might supply the current draft and the paragraph being edited. As a developer, you need to wire up the context that matters for your app. I’d start with a few useful IDs and the current selection, then make sure the agent can retrieve the corresponding content. For example, if somebody has selected a video description and asks to shorten it, I want that request tied to the selected draft. Having the agent guess from several similarly named documents would be frustrating. You can

[10:25] check that behavior directly while developing. Open one draft, make a manual change, and ask the agent to summarize the current version. Then switch to another draft and repeat the request. The response should follow the object you’ve actually opened. That gives you a practical way to evaluate the context layer before you build a much larger workflow around it. The framework also supports shared database back data. That lets the UI and agent work with the same stored records, while application state describes things like the current selection. Those two pieces

[10:56] serve different purposes and both are useful in this kind of editor. Personally, I’d start by customizing a single workflow in one of the examples. For slides, that could be a repeatable presentation format for your channel. For a content app, it could be drafting and revising descriptions. Choose one operation that you can perform both manually and through the agent. Then check what happens when you alternate between them. Does the agent preserve the human edit? Does the interface show the latest result? Can you recover if the revision

[11:26] goes in the wrong direction? Those are the details I’d want to get right before adding more capabilities. And because you have the source code, you can also use something like Claude Code or Codex to customize the application itself. This is where it gets pretty interesting. Open the generated project folder in your coding agent and ask it to inspect the existing structure first, then describe the change you want in normal language. For example, I could say, “Add a review checklist to each presentation. Let me mark the content design and technical accuracy as reviewed through

[11:57] the interface. Save those choices with the deck and let the embedded agent read and update the same checklist through shared actions. Follow the existing patterns in this project.” So, now we’re giving the coding agent a specific feature to build, including how it should work for both the person using the interface and the agent inside the app. Once it makes the changes, run the app locally and check the result. Tick an item yourself, then ask the embedded agent which checks are still incomplete. That gives you a simple way to see whether both sides are working with the same saved information, and you can keep

[12:29] refining it. Move the checklist beside the slide preview, make it more compact, or add a review status to the deck list. Describe what you want, inspect the changes, and test the workflow again. Personally, I think this makes the open-source part much more useful. You have an existing application to start from, and a coding agent can help you adapt it to the way you actually work. Now, there are some limitations to keep in mind. The example apps are labeled alpha, and connecting an agent to an editor doesn’t guarantee that every edit will be good. You’ll still need to

[12:59] evaluate the model, the prompts, and the way your actions handle changes. And if your entire use case is asking a question and reading a short answer, a simple chat interface may already do the job. I think this approach becomes more useful when people need to browse, select, edit, and review the work over several rounds. A presentation is a good example because the order, layout, and exact wording all matter. A content calendar or a document editor could benefit for similar reasons. What I like about the architecture is that it gives you concrete places to work on those interactions.

[13:30] You have application actions to inspect, data to update, and context to pass from the interface. That makes the workflow something you can build and evaluate step-by-step. So, if you want to try this, open the Agent Native website through the link in the description. Start with an existing app, make something small, edit it yourself, and ask the agent to continue. Then, open the source and customize the part that would make it useful for your own workflow. Overall, it’s a pretty cool. Anyway, let me know your thoughts in the comments. If you like this video, consider donating through the Super Thanks option or becoming a member by

[14:01] clicking the join button. Also, give this video a thumbs up and subscribe to my channel. I’ll see you in the next one. Until then, bye.