Agent-Native + Claude Code: Finally! Apps Your AI Agent Can Actually Work In (Open Source)

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: English

Original video: Agent-Native + Claude Code: Finally! Apps Your AI Agent Can Actually Work In (Open Source) · Channel: AICodeKing · 14:01 · Watch on YouTube

Topics: AI agents, Claude Code, Software engineering with AI, AI content generation

Summary

The video demonstrates Agent Native, an open-source TypeScript framework for building AI agents into interactive applications, using its Slides app as an example. The presenter creates a deck, edits its wording and slide order manually, and then asks the agent to revise the updated presentation while preserving those changes. The walkthrough also covers running the project locally, how shared actions and application context connect the interface with the agent, and how Claude Code or Codex can help customize the app. The video notes that the example apps are alpha and that users should evaluate the model, prompts, and editing workflow.

Key points

Agent Native is an open-source TypeScript framework that supports React, lets developers bring their own model, and keeps application code in their own repository.
The Slides app supports creating decks with prompts, starting from templates, importing presentations, editing text and slide order, and exporting to HTML, PDF, PPTX, or Google Slides.
The demonstrated workflow combines agent-generated drafts with direct human edits, then asks the agent to continue from the changed presentation.
Selecting text and choosing “revise with AI” gives the agent a specific target for a focused edit.
The slide starter requires Node version 22.22 or later and PNPM; model usage and chosen infrastructure may have costs even though the framework is free and open source.
Shared actions define operations, inputs, and validation that can be called from the interface and the agent.
Application context, such as the current view, selected slide, or selected draft, helps the agent work on the correct content.
Developers can test context by manually changing an item and asking the agent to respond to its current version, then repeating with another item.
Claude Code or Codex can help customize the generated project, such as adding a review checklist that both the interface and embedded agent can access.
The example apps are alpha, and an agent-enabled editor still requires evaluation; the approach is most useful when users need to browse, select, edit, and review work over multiple rounds.

Chapters

Start	Chapter	Summary

Quotes

sometimes you just want to click the text and fix it yourself. — 00:02

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. — 03:40

You maintain the validation and rename logic in that shared action. — 08:53

The response should follow the object you’ve actually opened. — 10:25

I think this approach becomes more useful when people need to browse, select, edit, and review the work over several rounds. — 12:59

Concepts and entities

Agent Native, Builder, Slides, React, OpenRouter, Ollama, Claude Code, Codex, MCP

Full transcript (original language)

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.