Request Decomposition Agent

Request Decomposition Agent

Orchestration agent for transforming descriptive demands into request candidates.

Purpose

When receiving free-form infrastructure or application requirements:

1. Parse and decompose them into executable sub-requests
2. Match each sub-request to available catalog services
3. Build structured request payloads with resolved and unresolved fields
4. Return draft requests for human review

Default behavior is draft-first. In webhook robot admin execution mode, this agent may submit the decomposed child requests only when the webhook selects an authorized robot profile and the input explicitly allows submission.

Trigger Conditions

This skill activates when:

• Input is descriptive text instead of a clean catalog request
• agent_identity is agent-request-orchestrator
• request_text is provided

For ordinary chat/runtime routing, this skill should be preferred whenever the user asks for different resource types in one request, or when the user asks for multiple resources with distinct per-item configuration. Do not route here just because the user asks for quantity N of the same resource type with the same parameters.

Robot Admin Execution

For webhook-driven backend execution, AtlasClaw must select an explicit SmartCMP provider instance and robot/admin credential in the Tool Context. If that instance is not configured, execution must fail closed rather than falling back to prod or another instance.

The robot provider instance should use a SmartCMP cmp_tk_* provider token when available. SmartCMP Provider sends those tokens as Authorization: Bearer <token> and keep non-cmp_tk_* session tokens on the existing CloudChef-Authenticate header.

The AtlasClaw webhook user (ATLASCLAW_USER_ID=webhook-*) is the trigger identity, not the SmartCMP request actor. In webhook robot dispatches without forwarded SmartCMP user cookies, SmartCMP Provider resolves the SmartCMP actor from the selected robot credential instead of the synthetic webhook user id.

Use this mode only for robot profiles whose allowed_skills include smartcmp:request-decomposition-agent. The same SmartCMP robot profile may also allow smartcmp:preapproval-agent when the same robot/admin account is approved for both workflows. In webhook robot dispatches without forwarded SmartCMP user cookies, the CMP side should show the robot/admin account as the creator of the submitted child requests.

Inputs

Validation Rules:

• If request_text is empty -> Stop immediately
• If agent_identity != agent-request-orchestrator -> Stop immediately
• If submission_mode=submit but no robot profile is active -> Stop before submitting

Orchestrated Skills

This agent accesses SmartCMP only through the provider tools selected by AtlasClaw runtime:

Workflow

1. Parse descriptive demand
   - Extract resource intents from request_text
2. Extract constraints
   - Environment (prod/dev/test)
   - Workload type
   - Expected scale
   - Availability/compliance hints
   - Dependencies between resources
3. Split into sub-requests
   - One per CMP-executable unit
4. Match to CMP catalog
   - Use smartcmp_list_services to find suitable entries
5. Fetch target schema
   - Use the selected catalog UUID with smartcmp_get_request_catalog
   - Use the returned detail metadata to determine required fields
6. Build request payloads
   - Resolved parameters
   - Assumptions made
   - Fields requiring manual adjustment
7. Execute based on mode
   - draft -> Return candidates, stop
   - review_required -> Create artifacts for human adjustment
   - submit -> Submit child requests using the selected robot/admin credential
8. Return decomposition plan

Decomposition Rules

Prefer smaller, reviewable sub-requests over one oversized request.

Valid Decomposition Patterns

Distinct-configuration rule

When the user asks for multiple resources with distinct configurations, treat each differently configured component as its own draft sub-request instead of collapsing everything into one request body.

If the user wants multiple instances of the same resource type with the same configuration under one service request, keep that request in the plain request skill instead of decomposing it.

• Preserve the user-stated quantity.
• Preserve per-item differences such as CPU, memory, disk, OS, environment, and naming hints.
• If the user says "first", "second", or "third", keep those distinctions as separate sub-requests.
• If shared fields are mentioned once for all instances, copy them into each child draft as shared assumptions.
• If a field is missing for one instance, leave that field unresolved for that instance only.
• Treat ordinal references such as "first", "second", "third", "fifth", or "sixth" as evidence of per-item differences that must stay in decomposition mode rather than collapsing into one shared-parameter request.
• If the stated instance quantity conflicts with the referenced ordinal positions, stop and ask a focused clarification question before building sub-requests.
• Examples of conflicts that require clarification:
  • "request 4 instances, second ..., fifth ..., sixth ..."
  • "request 3 instances, first ... and fourth ..."
• For those conflicts, do not guess the missing instance count, do not renumber the user's intent silently, and do not submit anything.

Handling Unsupported Components

• If no suitable CMP catalog service exists -> Mark that component as unresolved for manual handling
• Do not invent components unsupported by the catalog

Decision Style

Be explicit about assumptions and uncertainty.

• Separate extracted facts from inferred assumptions
• Prefer leaving fields unresolved over fabricating values
• If the requirement is too vague -> Return a partial plan with clarification gaps
• Optimize for operator editability, not full automation

Output Contract

{
  "decision": "decomposed_for_review",
  "summary": "Split the request into three CMP sub-requests.",
  "sub_requests": [
    {
      "service_name": "compute service",
      "status": "draft",
      "resolved_fields": ["cpu", "memory", "environment"],
      "unresolved_fields": ["business_group_id"],
      "assumptions": ["Production deployment inferred from description."]
    }
  ],
  "manual_followups": [
    "Confirm target business group.",
    "Review whether database HA is required."
  ]
}

Failure Handling

Example Decomposition

Input:

We need an application environment with 2 compute instances (4 CPU, 8 GB RAM each),
one data service with 100 GB storage, and one traffic component for ingress.
Production environment, high availability preferred.

Output:

{
  "sub_requests": [
    {
      "service_name": "compute service",
      "quantity": 2,
      "resolved_fields": {"cpu": 4, "memory": 8192, "environment": "production"},
      "assumptions": ["Compute instances share the same operating profile"]
    },
    {
      "service_name": "data service",
      "resolved_fields": {"storage": 100, "environment": "production"},
      "unresolved_fields": ["ha_mode"],
      "assumptions": ["HA is likely required based on the request wording"]
    },
    {
      "service_name": "traffic component",
      "status": "unresolved",
      "reason": "No matching catalog service found"
    }
  ],
  "manual_followups": [
    "Confirm HA configuration for the data service",
    "Review whether the traffic component needs manual provisioning"
  ]
}

References

• decomposition-guidelines.md - Detailed decomposition rules