No-code agent specs and tool permissions
AshnaAI’s agent builder writes a structured spec, not a free-text prompt dump. Tools are attached by internal IDs. Permissions that need OAuth or extra user data are requested in schema instead of being invented by the model.
Method: Review of the agent-builder output schema, TOOL_PERMISSION records, tool-selection phase, and the rule that only platform tool IDs may be assigned.
Key findings
- The builder emits TOOL_PERMISSION objects that reference existing internal tool IDs. Fake tools are forbidden in the schema instructions.
- Tool selection is a named builder phase with its own model assignment, separate from prompt repair and clarification.
- If a tool needs OAuth, an email, a URL, or an API key, the spec must request that data instead of attaching the tool silently.
Spec first, prompt second
A no-code agent that is only a prompt will drift. AshnaAI’s builder produces a spec: goal, selected tools, permission objects, and whether tool calling is auto or none.
Prompt quality is handled by a rectifier workflow. That workflow can repair wording. It cannot invent a tool that the platform does not have.
Tool permissions as data
TOOL_PERMISSION is a discriminator in the builder output schema. Each record points at an internal tool ID. The instructions say not to add fake tools and to pull IDs from the available tool list.
When a tool needs OAuth, a verified URL, or an API key, the spec stores a data request. Runtime then asks the user instead of failing mid-task with a missing secret.
Named builder phases
Tool selection is a named phase, not an afterthought inside one mega-prompt. The builder also has a clarification gate and compact repair. Those phases exist so a vague request becomes a spec instead of a hallucinated agent.
The commercial how-to is the agents guide. Website embed is a separate job with its own URL. WhatsApp Business is a messaging connector, not an inbound agent channel.
Limitations
The builder cannot create a website, a custom HTTP integration that is not already a tool, or a Tally write without the desktop bridge. Those limits are product boundaries, not prompt failures.
API consumers should start at /api-docs after they understand the spec shape described here.
Frequently asked questions
- What is an AshnaAI agent spec?
- A structured description of the agent’s goal, selected tools, permissions, and whether function calling is auto or none. It is the artifact the builder produces from a user request.
- Can the builder invent a new integration?
- No. It may only assign tool IDs that already exist on the AshnaAI platform. Missing connectors stay missing until they are built as real tools.
- How do tool permissions work?
- Each attached tool is a TOOL_PERMISSION record. If the tool needs extra user data, that request is stored on the record instead of being guessed later at runtime.
- Is this the same as writing a long system prompt?
- No. A system prompt is prose. The spec is typed: tool IDs, permission discriminators, and a function-calling mode. Prompt quality is a separate rectifier workflow.
- Can I share or schedule an agent after the spec exists?
- Yes. The product path after spec creation is attach tools, set schedule or share settings, then run. The how-to blog covers the user steps.
- Does no-code mean no guardrails?
- No. Guardrails are the permission records, the clarification gate, and human-in-the-loop tools used when a write is irreversible.
Related
Try this in AshnaAI. Create a free account.