Skip to main content
Use this page when a coding agent is asked to create or edit a Veryfront project agent, for example: “Build me a Gmail agent”.

Agent-facing flow

  1. Load the Veryfront skill: load_skill({ "skillId": "veryfront" }).
  2. Treat this page as the source of truth for the create-agent task. Do not call load_skill({ "skillId": "create-agent" }).
  3. The bare Studio starter is for a tool or integration agent by default. If the request is too broad to act on, ask one short form_input with one required brief field for the service/tool and job to automate, then continue from the submitted brief.
  4. Inspect only what the brief needs: existing agents, relevant project files, and the integration and MCP tool catalogs.
  5. Search integrations before choosing third-party tools. When the brief names or implies a service, call list_integrations with search: "<service>", then call get_integration for exact integration tool IDs and setup details.
  6. Use tool_search only to progressively load executable tools for the current run. It is not the agent-authoring catalog. Call tool_search with query: "list_agent_tool_references", then call list_agent_tool_references with the selected project_reference and a capability query or exact names. Use the exact returned name values in tool_ids. The response omits schemas and does not provide provider_tool_ids.
  7. Before creating a new Studio project agent, call create_agent_avatar with assign: false, then pass the returned avatar_url into create_agent.
  8. Create or update the project agent, re-read or list the agent when a read/list tool is available, then summarize briefly and stop. Report the agent name, id, source path when available, selected integration, and chat action in the final response.

Guardrails

  • Do not load a removed create-agent sub-skill. Always load veryfront, then this docs page.
  • Do not call load_skill({ "skillId": "create-agent" }).
  • Do not invent integration IDs, tool IDs, provider tool IDs, files, routes, agents, or capabilities.
  • Do not create app, page, route, or chat UI files just to expose an agent. Studio exposes agents directly.

Tool selection

Use Choose agent tools for common project-agent patterns such as Knowledge Q&A, web research, file work, integration assistants, human input, delegation, and sandbox execution.
  • Search integrations with list_integrations, then use exact integration tool IDs returned by get_integration.
  • Use tool_search only to progressively load executable tools for the current run. It is not the agent-authoring catalog.
  • Load list_agent_tool_references with tool_search, then call it for the selected project and source target. Use exact returned name values in tool_ids. Do not rename, prefix, or infer tool IDs.
  • Use list_tools when you need to inspect project-local tool definitions. Use get_integration for integration setup and exact integration tool IDs.
  • Use only tool IDs returned by the platform catalog, integration catalog, or current project. Do not invent IDs.
  • Put project and integration tools in tool_ids.
  • Put provider-native tools in provider_tool_ids.
  • Set the prompt with system only. Do not also send system_prompt; it is a compatibility alias.
  • For project Knowledge Q&A, include both search_knowledge and get_file in ordinary tool_ids.
  • Tell project-knowledge Q&A agents to use search_knowledge for discovery, then use get_file to retrieve body content before answering. search_knowledge returns paths and frontmatter metadata, not file bodies. matched_fields describes metadata matches and can be [] for browse-style results. The agent must say when the project knowledge does not support an answer only after reading relevant candidates or retrying with a refined query.
  • Add these rules to the Knowledge Q&A system prompt: “The platform attaches exact source citations automatically after successful get_file reads of knowledge files. Do not write a manual Sources section or retype source paths. Treat returned source paths as opaque identifiers. If you mention one inline, copy it character-for-character from the latest search_knowledge or get_file result; never shorten, normalize, or reconstruct it.”
  • Do not use knowledge_lookup. It is a legacy internal helper, not a project-agent tool.
  • Choose the smallest useful tool set for the brief.
  • Do not create a role-only helper unless the user explicitly asks for a no-tool or no-integration agent.
  • Do not create app, page, route, or chat UI files just to expose an agent; Studio exposes agents directly.

Agent shape

A useful project agent usually has:
  • a concise name and description
  • a short system prompt with scope, capabilities, guardrails, and response style
  • a model and step limit appropriate for the task
  • a few practical suggestions
  • only the tools required by the brief
  • an avatar_url from create_agent_avatar for new Studio project agents

HITL, human input, and security

Do not treat security_enabled as HITL approval. security_enabled is a guardrail/security setting for the project-agent document; it is not a per-tool approval gate and does not pause tool execution for human sign-off. Use form_input when an agent needs structured input from a user during a run. A confirm field can collect an approval-shaped response, but form_input itself is a human-input primitive, not a global tool-approval policy. Use Studio Require approval for hosted project-agent tool approval when the agent should ask before using tools. For workflow-level approval in Veryfront Code, use waitForApproval. For Claude-code workflow tool approval, use ToolApprovalConfig.

Example pattern

For a Knowledge Q&A request, search platform tools for knowledge, attach both search_knowledge and get_file, and tell the agent to read matched file content before answering. When search_knowledge returns candidates, read up to 3 of the most relevant bodies with get_file before declaring the knowledge base unsupported. If the candidates do not support the answer, refine the query and retry. For a Gmail request, search the catalog for gmail, read the returned integration details, select only the mail actions needed by the brief, and pass those catalog-returned IDs to create_agent. For a different service, follow the same pattern with that service name. The catalog is authoritative. Use the framework source tab for file-based Veryfront Code. Use the MCP tool call tab for the Studio or Cloud control-plane action.
Use system as the canonical prompt field in both Veryfront Code and MCP tool input. The system_prompt field remains a compatibility alias for older clients. The tools object maps to verified tool_ids or provider_tool_ids. Suggestions stay practical, short, and user-facing. The agent must still use live catalog results before choosing tool IDs.

Output shape

Return the created or updated agent name, agent ID, source path when available, attached tool IDs, selected integration, chat action, and 2-3 starter suggestions. Keep the final answer brief and do not say the agent was not created after a successful create_agent or update_agent result.