标签：#agentskills

A2A has become like a standard for enabling agent to agent communication, we could use the a2a-sdk for running and configuring the a2a server and its features such as agent card, agent skills, agent executor, request handler etc. However we are going to go with a simplified approach here with strands where the agent card will be fetched automatically. Let's get started! Server Initialize a uv project for the a2a server and switch to that directory. uv init ~/strands-a2a-server cd ~/strands-a2a-server Add the required packages. uv add python-dotenv == 1.2.2 strands-agents[a2a] == 1.42.0 Change the code in main.py to look like below. $ cat main . py from dotenv import load_dotenv from strands import Agent from strands.multiagent.a2a import A2AServer load_dotenv () def main (): agent = Agent ( callback_handler = None , description = " A sample strands agent " , model = " us.amazon.nova-micro-v1:0 " , ) a2a_server = A2AServer ( agent = agent ) a2a_server . serve () if __name__ == " __main__ " : main () I like the simplicity here, as you see above, it's quite simple to start a basic a2a server from with in strands, with just a couple of lines of code, we didn't have to install the a2a-sdk separately. Run the code, to start the a2a server. $ uv run main.py INFO: Started server process [18006] INFO: Waiting for application startup. INFO: Application startup complete. INFO: Uvicorn running on http://127.0.0.1:9000 (Press CTRL+C to quit) Client Let's now do the client part on a separate terminal. Initialize the project and switch the directory. uv init ~/strands-a2a-client cd ~/strands-a2a-client Modify main.py code to look as follows. import asyncio from strands.agent.a2a_agent import A2AAgent async def main (): agent = A2AAgent ( endpoint = " http://localhost:9000 " ) agent_card = await agent . get_agent_card () print ( " Invoking remote agent with agent card: " ) for key , value in agent_card : print ( key , " : " , value ) print ( ' - ' * 20 ) while True : prompt = input

Anthropic published a thoughtful guide to making skills. It is worth reading, but it's a map of work you should not have to do. The Claude Code team wrote a piece on how they use agent skills . If you make skills, read it. It is honest and tells you something important: making a good skill is real work. Here's what the guide covers. It sorts skills into nine categories. It explains progressive disclosure, where the agent knows which files to load and when. It covers scripts, config files, combining skills together, and writing the description so the model reaches for the skill at the right moment. All of that is true and useful. It is also a lot to learn. And most of it exists only because you are doing the work by hand. We're SkillsCake . We make and score agent skills all day. So we read this guide a little differently than someone meeting skills for the first time. Here's what we think. Skills are infinite The guide splits skills into types: library reference, verification, and so on. That is a helpful way to teach a class. It is not what a skill actually is. A skill is prose that tells an agent how to do one thing, sometimes with scripts attached. The set of possible skills is not nine boxes. It is every job you could describe in writing; it's infinite. Categories are how a person gets a handle on something that open-ended. They are scaffolding for learning, not the shape of the thing. This matters because the moment you think in categories, you start bending your skill to look like the example in its bucket. Your real job rarely fits the bucket. The best engineered skill is the one written for your exact task, by an expert. Doing it yourself might not be worth it Progressive disclosure, scripts, config, descriptions tuned for the model, gotchas earned by failing, and eval loops: none of that is busywork. It's how a good skill gets built by hand. The guide is not overcomplicating anything. It is being honest about what the manual path costs. But that is the poin

I’ve spent a lot of time lately thinking about why some LLM agents feel "intelligent" while others just feel like chatbots with a slightly better prompt. It almost always comes down to how the system handles memory. When we treat the context window as the only place for state, we hit a ceiling very quickly. To build an actual agent, we have to move away from "one big prompt" and toward a layered memory architecture. Agentic Memory can be categorized in 4 layers by their function: Working Memory: The current context window. It's our RAM—fast, essential, but wiped clean after every session. Semantic Memory: The Vector DB or knowledge base. This is where the "world rules" and global conventions live. It’s the reference manual the agent checks to stay aligned. Procedural Memory: The "how-to" layer. Instead of stuffing every tool description into the prompt, the agent maintains a lean index of skills and pulls in the full implementation only when a specific task triggers it. This keeps the context window clean. Episodic Memory: This is the hardest part. It's the ability to distill a past interaction into a reusable insight. The real engineering challenge here isn't storage—it's the "forgetting" logic. Deciding what is noise and what is a core pattern is where most frameworks still struggle. Depending on the use case, the architecture changes: Reflex Agents: Just Working Memory. Support Agents: Working + Procedural. Coding Agents: The full stack. The gap between a demo and a production-ready agent is usually the distance between simple RAG and a functioning episodic memory. The ability to compress experience into a usable state is still a significant hurdle. Which of these layers are you currently implementing, and how are you handling the "forgetting" logic in your episodic memory?