Agent Generation with Prompt

What is this feature?

Agent Generation with Prompt turns a plain-language request into a structured agent configuration. The generated result can include architecture decisions, agent definitions, tools, knowledge bases, and guards that are suitable for a workgroup draft.

Inputs and Configuration

This feature uses a JSON request with two top-level parts: input and config.

Required: input.user_query (string)

Your instruction describing what the agent should do.

Example:

{
  "input": {
    "user_query": "Create a simple calculator agent that can add, subtract, and explain steps."
  },
  "config": {
    "provider": "openai"
  }
}

Required by provider

config.provider selects which provider is used for generation. The currently supported values are:

• openai
• azure_openai
• gemini
• vertex_ai

Depending on that value, the service requires additional fields in input:

• OpenAI

  • input.api_key (string)
  • optional: input.model_name
    If omitted, the service defaults to gpt-5.2.

• Azure OpenAI

  • input.api_key (string)
  • input.azure_endpoint (string)
  • input.api_version (string)
  • optional: input.model_name or input.azure_deployment
    If omitted, the service defaults to gpt-5.2.

• Gemini

  • input.api_key (string)
  • optional: input.model_name
    If omitted, the service defaults to gemini-2.5-pro.

• Vertex AI

  • input.project (string)
  • input.location (string)
  • input.service_account_info (object)
  • optional: input.model_name
    If omitted, the service defaults to gemini-2.5-pro.

Model version limits

The handler validates minimum model generations:

• OpenAI and Azure OpenAI models must be gpt-5.2 or newer
• Gemini and Vertex AI models must be gemini-2.5 or newer

Optional inputs

You can also provide:

• input.internal_tools (array): tools you want the agent to be allowed to use
• input.knowledge_bases (array): knowledge base configs to attach for retrieval
• input.mcp_servers (array): MCP servers and which tools to expose
• input.llm_guards (array): safety/validation checks to apply
• input.model_config (object): model tuning parameters for the generation step

Outputs

The generated response includes these top-level fields:

• guards_passed (boolean)
• decision:
  • PROCEED when the request is allowed
  • REJECT when the request is refused
• reject_reason (only when decision = REJECT)
• reasoning_output: a structured, human-readable decision record
• architecture (only when decision = PROCEED)
• main_output (only when decision = PROCEED): the generated agent/workgroup configuration

If generation fails, the response contains an error with a message.

Example response shape

{
  "guards_passed": true,
  "decision": "PROCEED",
  "reject_reason": null,
  "reasoning_output": {
    "step_2_architecture_decision": {
      "selected_architecture": "single"
    }
  },
  "architecture": "single",
  "main_output": {
    "decision": "PROCEED",
    "architecture": "single"
  }
}

Limitations

• This feature generates configuration; it does not execute your agent’s tasks.
• The generated configuration should be reviewed before production use (especially tool permissions and data access).
• The service returns guards_passed, but generation quality still depends heavily on the completeness of your prompt and the tools/knowledge bases you provide.
• Provider and model validation happens before generation starts.

Common Mistakes

• Missing or non-string input.user_query.
• Selecting a provider in config.provider but not providing the required provider-specific fields in input.
• Using unsupported provider names such as azure-openai or vertex instead of azure_openai and vertex_ai.
• Expecting the service to fully finalize every operational detail. The output is a scaffolded configuration that you should still review in the product UI.