forgive these highly disorganized thoughts. working with agents on this to organize and plan

we have a fragmented system

the agent system is not utilizing hypermedia primitives. data is not stored in ipfs, and our mechanisms for collaboration are not integrated.

agents run in the agent servers but are not deeply baked into core hm nodes. maybe this is a mistake

our documents/resources do not support arbitrary schemas, which leads to a lack of exstensibility

as for tool calling: agent tools are defined with input/output schemas as well as a type. this leads to a sort of schema system that we want to be harmonious with hm resource schemas

how do agents and tools interact with eachother?

agents should be able to interact with other agents. some agents will have more or less capabilities- access to different keys, different networks, code execution

can one agent provide tools to another agent?

when an agent writes code, can it expose that as a user-facing tool? for tools/scripts that are written by an agent, can it use the same interface as the tools that the agent itself has access to? the code that an agent writes should be able to use the agent's tools like an sdk. I may not want to burn tokens every time i leverage an agent.

we should also consider cost, budgeting, and permissions at every level of the stack. can one tool sell access to another tool? can I give a budget to an agent who then delegates budget to sub-agents? the budget may include token usage, compute usage, data storage in the ipfs layer, network access (like residential IPs for web scraping) or external apis.

should an agent be able to read context from other sessions within its own scope? probably.

should an agent be allowed to reconfigure itself or does it strictly reconfigure sub-agents?

this ties in with our future plans for extensibility and plugins in the hypermedia ecosystem. we desperately need these systems but they need to be secure.