{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiftzwfunrna5kq2vrerrgvxxjxske3okcsxiwoldoptczpoddhuau",
    "uri": "at://did:plc:pm3aahxqly7iwm2fs65fic22/app.bsky.feed.post/3mgodlmqjyrw2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreig5w4wu54br243j4mfoh2yqxoqm3wlgkdyjdr4l5cvrae3dx3wtsy"
    },
    "mimeType": "image/png",
    "size": 417670
  },
  "path": "/2026/03/09/Agent-Resources-And-Tools",
  "publishedAt": "2026-05-15T13:19:10.262Z",
  "site": "https://blog.lhotka.net",
  "tags": [
    "RockBot",
    "Sample agent",
    "Research agent",
    "RockBot maintains long-term memory",
    "RockBot also maintains working memory",
    "RockBot has skills",
    "mcp-aggregator",
    "calendar-mcp",
    "onedrive-personal",
    "onedrive-marimer",
    "todo-mcp",
    "routing-stats",
    "openrouter"
  ],
  "textContent": "An AI agent, by itself, can’t actually do anything besides chat. And while it can be fun to have philisophical debates in isolation for a while, eventually we all want to get about the business of actually _doing things_.\n\nAgents do things by calling functions or tools. These functions and tools are provided to the agent (the LLM) by the hosting runtime. For example, RockBot is a host that provides a set of tools that can be used by the AI agent.\n\nThe RockBot _framework_ provides access to a whole set of subsystems, each of which provides tools and guidance to the agent on using the tools. The RockBot _agent_ uses all the features of the framework, plus other capabilities.\n\nYou can think of these tools as being in logical groups by subsystem.\n\n## Tool Discovery\n\nEach subsystem provided by the RockBot framework has the ability to provide its own base-level tool guide to the agent. This way the agent immediately knows how to use things like memory, skills, MCP servers, etc.\n\n  * list_tool_guides, get_tool_guide\n\n\n\nWhen a subsystem is registered during app startup, its tool guide is added to the master list of guides, making it easy for the agent to get the appropriate guide to function. Skills layer on top of these guides, allowing the agent to learn over time.\n\n## Scheduling Tools\n\nThese are tools that allow the agent to schedule tasks to run at specific times.\n\n  * schedule_task — Schedule one-time or recurring tasks (cron)\n  * cancel_scheduled_task — Cancel a scheduled task by name\n  * list_scheduled_tasks — List all scheduled tasks\n\n\n\n## Subagent Tools\n\nThese tools allow the primary RockBot agent to spin off subagents to work in the background. Each subagent has access to the same tools and skills, but has its own context memory and a slice of working memory for sharing information with the primary and other subagents.\n\n  * spawn_subagent — Spawn an isolated subagent for complex/long-running tasks\n  * cancel_subagent — Cancel a running subagent by task ID\n  * list_subagents — List active subagent tasks\n  * report_progress (subagent-only) — Report progress back to the primary agent\n\n\n\n## Agent-to-Agent (A2A) Tools\n\nSometimes a subagent isn’t enough, and it is necessary to interact with other autonomous agents in the environment. These tools allow the RockBot agent to interact with other autonomous agents.\n\n  * invoke_agent — Call an external A2A agent by name and skill\n  * list_known_agents — List all known external agents\n\n\n\nIn a business environment, you can imagine how your agent might interact with other agents that help to manage sales, inventory, production, delivery, finance, and other automation across your organization.\n\n### Agent Examples\n\nIn the RockBot repo there are two agents to demonstrate how to use the RockBot framework to build agents other than RockBot itself. The first is as simple as you can get. The second is a real external agent that the RockBot agent uses when asked to do any research.\n\n  1. Sample agent - Agent that echoes any text sent\n  2. Research agent - Agent that researches a topic and returns consolidated results\n\n\n\n## Memory Tools (long-term)\n\nRockBot maintains long-term memory, and these are the tools that support that memory concept.\n\n  * save_memory, search_memory, delete_memory, list_categories\n\n\n\n> ℹ️ There are no explicit tools for _conversational memory_ because conversational memory is always part of the agent’s context window. Other memories are brought into context on-demand.\n\n## Working Memory Tools (session scratch space)\n\nRockBot also maintains working memory, and these are the tools for interacting with that memory.\n\n  * save_to_working_memory, get_from_working_memory, delete_from_working_memory, list_working_memory, search_working_memory\n\n\n\n> ℹ️ As you can see, the RockBot framework and agent have three levels of memory: conversational, working, and long-term. This provides a rich way to manage context window usage, subsystem interactions, and long-term concepts in an elegant manner.\n\n## Skill Tools\n\nRockBot has skills, and these are the tools it uses to interact with its own set of skills.\n\n  * get_skill, list_skills, save_skill, delete_skill\n\n\n\nSkills develop over time automatically, sometimes refining the base-level subsystem tool guides, other times being created out of whole cloth by the agent as it learns.\n\n## Rules & Configuration Tools\n\nThese are tools used to manage rules that alter the agent’s behavior. These rules are in addition to the built-in `soul.md` and `directives.md` files that are central to the agent’s identity.\n\n  * add_rule, remove_rule, list_rules, set_timezone\n\n\n\n## Web Tools\n\nThese are tools that allow the agent to search (using a Brave API key) and retrieve web pages.\n\n  * web_search — Search the web, returning titles/URLs/snippets\n  * web_browse — Fetch a page and return content as Markdown (with chunking)\n\n\n\n## MCP Integration Tools\n\nThese are tools that allow the agent to find and use MCP servers without having those MCP servers and tools always consuming large amounts of context memory.\n\n  * mcp_list_services — List connected MCP servers\n  * mcp_get_service_details — Get tool details for an MCP server\n  * mcp_invoke_tool — Execute a tool on an MCP server\n  * mcp_register_server — Register a new MCP server at runtime\n  * mcp_unregister_server — Remove an MCP server at runtime\n  * Plus all tools dynamically registered from configured MCP servers\n\n\n\n> ℹ️ These tools are a built-in equivalent to the separate mcp-aggregator project.\n\n### MCP Server Examples\n\nIn my current live environment, here are some of the MCP servers I have registered with the RockBot agent.\n\n  1. calendar-mcp - access all my email and calendar accounts\n  2. onedrive-personal - personal OneDrive\n  3. onedrive-marimer - work OneDrive\n  4. todo-mcp - a simple to-do list implementation\n  5. github - read/write to my GitHub repos\n  6. routing-stats - get info on RockBot LLM routing\n  7. openrouter - get info on openrouter.ai usage\n  8. azure-foundry - get info on Azure Foundry usage\n\n\n\n## Script Execution\n\nWhen an agent needs to run some code, it uses these tools to execute scripts. The script executes in an ephemeral container that runs in a separate Kubernetes namespace.\n\n  * execute_python_script — Run Python in a secure ephemeral container\n\n\n\nIn the future we may support other types of script, such as TypeScript or bash. Python was the obvious start point given its broad use, flexibility, and how well LLMs can generate Python code.\n\n## Conclusion\n\nAgents without tools aren’t very useful in any real-world scenarios. The RockBot framework provides a range of subsystems you can use when building an agent, and each subsystem provides a set of tools to the agent.\n\nThe RockBot agent itself has access to all these subsystems and associated tools. And some subsystems, like A2A, MCP, web, and scripts, open the door for the agent do do virtually _anything_ by collaborating with other agents or invoking external tools, APIs, or code.",
  "title": "Agent Resources and Tools",
  "updatedAt": "2026-03-09T00:00:00.000Z"
}