Agent Builder Archive

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 Issu

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

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

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 de

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 t

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: