Enterprise Problem Decoder

Enterprise Problem Decoder — Problem Decoding & Agent Specification

Map raw intake signals to a precise, structured agent specification. Resolve the platform, apply compliance constraints, classify the agent type, and produce a spec that enterprise-agent-builder can immediately turn into architecture and code.

Input

Accepts the intake YAML output from enterprise-signal-listener. If called directly, prompt for: the spoken problem description, platform hint, industry hint, and desired outcome.

Step 1 — Platform Resolution

Resolve the platform from the intake. If ambiguous, default to the most likely platform for the stated industry and build for it — note alternatives at the bottom of the spec.

See ../dynamic-enterprise-agent/references/platform-connectors.md for full API and connector details per platform.

Platform families and primary agent entry points:

Resolution rules:

• If multiple platforms are mentioned, identify the primary (trigger source) and secondaries (integration targets).
• If no platform is identifiable, ask: "Which system does this live in today?" before proceeding.
• If the platform is ambiguous between two options, resolve to the one with a stronger match to the industry context and state the alternative in the spec.

Step 2 — Industry Context Resolution

Apply industry-specific rules, compliance constraints, and data models automatically based on industry signals in the intake.

See ../dynamic-enterprise-agent/references/industry-patterns.md for the full regulatory and domain pattern library.

If no industry is identified: Apply baseline guardrails (audit logging, no irreversible actions without approval, credential hygiene) and proceed. Flag industry: [unspecified] in the spec.

Step 3 — Agent Type Classification

Classify the agent into exactly one of five types based on the decoded problem. When in doubt, choose the type that matches the primary pain trigger, not the secondary outcome.

Step 4 — Structured Agent Specification

Produce this specification immediately after Steps 1–3:

agent_spec:
  name: ""                    # proposed agent name (descriptive, platform-prefixed)
  one_liner: ""               # what it does in one sentence, in plain language
  type: ""                    # Monitoring | Triage | Automation | Decision-Support | Orchestrator
  platform:
    primary: ""               # resolved platform
    entry_point: ""           # specific API or integration point
    secondary: []             # any additional systems it touches
  industry:
    domain: ""                # resolved industry
    compliance: []            # list of frameworks auto-applied
    data_model: []            # relevant entities (Patient, Transaction, Incident, etc.)
  trigger:
    event: ""                 # what kicks the agent off
    source: ""                # which system sends the trigger
    frequency: ""             # real-time | scheduled (cron) | on-demand | event-driven
  actor_today: ""             # who does this manually today
  desired_outcome: ""         # what "done" looks like
  pain_intensity: ""          # low | medium | high | critical
  urgency: ""                 # demo_now | this_week | this_sprint | next_quarter
  alternatives_considered:    # if platform was ambiguous
    - platform: ""
      reason_not_chosen: ""
  open_questions: []          # any ambiguities that the builder should flag

Output

Produce the structured agent spec and a decoding summary:

DECODE COMPLETE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Agent: [agent name]
Type:  [agent type]
Platform: [primary platform] → [entry point]
Industry: [domain] | Compliance: [frameworks]
Trigger: [event] from [source system] ([frequency])

Agent Spec:
[populated agent_spec YAML]

Ready for: enterprise-agent-builder
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Hand off the completed agent_spec YAML to enterprise-agent-builder.