Teaching the Agent Without Losing Control
Once a host has chosen where Agentao runs, it still has to decide what belongs inside that boundary. This chapter separates the surfaces that add executable capability from those that add instructions, external connectivity, user interaction, observation, or lifecycle intervention. The practical outcome is a smaller and clearer design: a business API becomes a Tool, a working convention becomes a Skill or project instruction, an existing external ecosystem becomes MCP, and a moment of runtime control becomes a hook or policy decision.
The capability plane: what the agent can do
A custom Tool is the closest fit for a host-owned business action. It gives the model a named capability, a description, a JSON Schema for its arguments, and an implementation that returns a result for the next model step. The implementation can carry context that should never be delegated to the model. In a tenant-scoped project-management application, a tool can be constructed with the authenticated tenant and backend client, then accept only the project and task fields the model is allowed to propose. The model does not get to choose which tenant the backend query uses.
This division is important because a Tool has two interfaces. Its description and parameter schema are an interface for the model: they tell the model when the capability is relevant, what arguments mean, and what result to expect. Its execute() method is an interface for the real system: it must validate arguments, enforce business rules, bound response size, and handle backend failures. A clear description can reduce misuse, but it cannot authorize a refund, bypass a tenant check, or make an external API reliable. The host-owned implementation remains the final authority for its business action.
The decision to use a Tool should follow ownership. If the capability is an in-process API, database client, or object whose identity is tied to the current session, a Tool keeps that binding explicit. If the host does not need the model to see a capability, it should not register it merely because Agentao can expose it. Reducing the visible tool surface lowers the number of actions the model can propose, but the project documentation is explicit that tool allowlists are not authorization. A tenant that must never perform an action needs a permission or backend rule, not only a smaller schema.
A Skill solves a different problem. It is a Markdown bundle that teaches the model how to approach a task. Its front matter describes when it should be activated; its body can define a workflow, tone, constraints, and edge cases; its references can be loaded only when a special case requires them. A support-triage skill might say to fetch a customer profile, check an order, follow an escalation matrix, and draft rather than send when the case is ambiguous. It does not itself send the reply. That action belongs behind a Tool whose implementation can bind the ticket and enforce the sending policy.
Skills are useful because not every instruction should be present in every turn. Agentao can show a catalog of available skills and inject the full body only after activation. This allows a host to maintain several focused workflows without placing every rule in the prompt all the time. Project instructions play a related but broader role: they provide shared facts and hard constraints for a working directory. Both are model-facing inputs. They can improve consistency and make a risky instruction easier for the model to recognize, but they are not a durable authorization boundary.