Agent Builder Archive

Hey,Why would a plugin that returns the right data produce a wrong answer? I keep seeing the same thing: builders format their response into a clean paragraph using an LLM action, return it as text, and the assistant loses the ability to work with it.It comes down to what your output mapper returns.How the Engine Processes Your Tool ResponseWhen a plugin runs and returns data, that response passes through a processing step before the reasoning engine sees it. What the engine can do with your data depends entirely on whether it's structured JSON or flat text.Two-path comparison: structured JSON gets parsed, filtered, and routed while plaintext gets forwarded as-isStructured JSON gets parsed. The engine extracts the schema, trims irrelevant fields, and routes pieces to downstream tools like code execution or summarization. Only the relevant subset reaches the reasoner. Context stays clean.Flat text can't be parsed. The entire string gets forwarded to the reasoner as-is. No filtering. No

Hey,Your plugin didn't break in production. It was always going to degrade after a few turns. You just never had a conversation long enough to notice.By turn three or four, the reasoner — the agentic reasoning engine that orchestrates your plugin's conversation — starts repeating questions, hallucinating field values, forgetting what the user said two messages ago. The config didn't change. The context window filled up. Before your user said a single word, your plugin had already consumed thousands of tokens in slot descriptions, system prompts, action schemas, and resolver metadata. Every turn after that is a fight for what's left.We covered the architecture fix for chained actions in Issue #5. Today: the two places most builders waste context without realizing it.The Context BudgetEvery plugin has a context budget: the total information the reasoner can hold in working memory during a conversation. Slot descriptions, action outputs, conversation history, system instructions. All comp

Hey,Your plugin went from 2 seconds to 8 to respond to your user. You didn't change anything. You just added a second action to the conversation process, then a third, then a fourth. Now the user stares at a spinner and you're filing a bug about "slow plugin response times."It's not a platform bug. It's an architecture problem, and there's one golden rule that fixes it.The Golden RuleHere it is:Never execute two action activities in a row in a conversation process without collecting a slot in between.That's it. One sentence. The single most important architecture pattern in Agent Studio.Why it mattersHere's what actually happens when you chain actions in a conversation process. Conversation processes are deterministic code paths: the reasoner will execute each activity in order regardless. But between each action activity, the reasoner still has to process the output. Each action triggers a full reasoner turn — think about the output, figure out what it means, then move on to the next

Hey,I used to write slot descriptions like mini-prompts. "Extract the Jira ticket ID from the user's message. If they say 'my ticket,' look up their most recent open ticket." Paragraph-long instructions trying to get an LLM to do what a single API call could do.That's what resolver strategies replace.Last issue we unpacked the basics — inference policies, descriptions, validation. By the end of this one, you'll know how to wire up resolver strategies, when to use static vs dynamic resolvers, and how disambiguation keeps your plugin from guessing.One Big Thing: Resolver StrategiesSlots collect inputs. But "my bug ticket" isn't an ID. It's context. Something has to convert that into a structured value your action can use. That's what resolver strategies do.You can attach a resolver in two ways:On a custom data type (like JiraIssue) — reusable wherever that type shows up. If you reference the same business object across plugins, this is the move. Inline on the slot itself — tied to that o

The Agent BuilderYour plugin keeps asking users for things it should already know."What's your employee ID?" — it's in their profile. "Which ticket?" — they just mentioned it. "Who's the requester?" — obviously them.This is the slot inference problem. And once you understand how slots actually work, you stop building plugins that interrogate users and start building plugins that just... get it.By the end of this issue, you'll know how to configure inference, write tight descriptions, and validate inputs — so your plugin collects what it needs without wasting round trips.One Big Thing: Slots, UnpackedSlots are the inputs your plugin needs to do its job. "Close my Jira ticket" needs a ticket. "Book a meeting" needs attendees. "Submit PTO" needs dates.slots: ticket: type: u_JiraIssue description: "The Jira ticket to close" comment: type: string description: "Closing comment"But here's where it gets interesting: slots don't have to be collected by asking. The assistant can fi

HeyI built two Agent Skills last week.The first one turns rough text into polished frontend code using React and Tailwind CSS — drop in some ideas or a sketch, get back a website in seconds. The second one reads all my writing samples and generates a style guide so that anything my assistant writes next sounds just like me.Both took about 20 minutes. Just markdown files with clear instructions.Here's what a snippet of the 150 line voice-analyzer skill looks like:# Voice Analyzer SkillWhen given writing samples:1. Extract sentence patterns (length, rhythm, punctuation)2. Identify vocabulary preferences (technical vs. casual)3. Note structural habits (how paragraphs open/close)4. Output a style guide with 3-5 concrete rulesUse this guide when writing future content.They're simple. Markdown Files. No Infrastructure. No Loops. No Orchestration. Chef's kiss.And the whole time I kept thinking: this is exactly what we've been building in Agent Studio.The industry finally gets it: skills over

Welcome to the first issue of The Agent Builder — a lightweight update for the developers building agents. Editions will cover technical breakdowns, common patterns, actionable updates, and real builds. What are File Slots?Slots describe the inputs that your agent collects from a user to proceed with a task. File slots make it possible for your AI agents to collect files like expense receipts or invoice PDFs.File Slots help AI agents escape JSON to become Multipart.The core tension you may have come across: agent frameworks are JSON-first. LangChain, Semantic Kernel, even our old setup, everything flows through structured payloads. Files don't fit that model, so you rely on hacks:Base64-in-JSON: Bloats ~33%, longer transfers, memory spike on decode "Paste a link" strings: The backend fetches, there's auth headaches and timeout risks Custom multipart builders: They're a boundary creep and third-party libs can leak resourcesMultipart/form-data is the right way for binaries, they're effic