I'm the CEO of a translation company. Not an engineer.

In Part 1, I tried to connect Copilot Studio to LDX hub's StructFlow API and hit a wall before getting anything to work. This is Part 2 — the completion.

It works now.

I pasted meeting minutes into a Copilot Studio chat. It returned structured action items with assignees, tasks, and deadlines. It even interpreted "next week" as a specific date (May 8, Friday) based on the meeting date — and flagged it as an assumption for me to verify.

Here's everything that happened between Part 1 and that result.

The root cause of BadGateway

The HTTP action I'd been using — "Send an HTTP request" — was actually routed through the Office 365 Users connector, not a raw HTTP connector. That's why every request to LDX hub returned BadGateway.

The fix: use the green HTTP connector under "Built-in tools" in Power Automate. It looks similar to the white Office connector but behaves completely differently. The green one makes actual HTTP calls to external APIs.

This distinction isn't obvious from the UI. It cost me most of Part 1.

Switching to Agent Flows

The Power Automate flow I built never appeared in Copilot Studio's tool list, despite being in the same environment. I never resolved why.

The workaround: build the flow directly from Copilot Studio's left sidebar → "Flows" → "Agent flows." This creates a flow that's natively connected to the agent from the start.

Same green HTTP connector, same logic — just a different entry point.

The error log (all 8 of them)

I'm including every error in sequence. Each one moved me closer.

① BadGateway
Cause: Office 365 connector instead of HTTP connector.

② triggerBody()['text']['minutes_text'] cannot be evaluated
Cause: Agent flow triggers have a different body structure than Power Automate triggers.

③ Property 'minutes_text' doesn't exist, available properties are 'text'
Cause: The correct reference is triggerBody()['text'], not nested further.

④ Invalid or missing value for parameter: 'model'
Cause: gpt-4o isn't a valid model ID for LDX hub. The correct format is anthropic/claude-sonnet-4-6.

⑤ Invalid or missing value for parameter: 'example_output'
Cause: example_output is required. I'd omitted it.

⑥ The request body contains invalid or malformed JSON
Cause: The inputs parameter isn't a string — it's an array of objects with a specific schema.

⑦ Property 'output' doesn't exist, available properties are 'results, job_id, ...'
Cause: The results field is called results, not output.

⑧ Variable 'job_status' of type 'String' cannot be updated with value of type 'Array'
Cause: results is an array. The variable holding it needs to be typed as Array, not String. Needed a separate String variable for the status field.

The working request body

{
  "model": "anthropic/claude-sonnet-4-6",
  "system_prompt": "Extract action items from the meeting minutes. Return assignee, task, and deadline in structured format.",
  "example_output": {
    "action_items": [
      {
        "assignee": "Tanaka",
        "task": "Prepare the report",
        "deadline": "End of May"
      }
    ]
  },
  "inputs": [
    {
      "id": "0",
      "data": {
        "minutes": "@{triggerBody()['text']}"
      }
    }
  ]
}

Key differences from what I'd been trying:

• inputs is an array of {id, data} objects, not a plain string
• model requires the provider-prefixed format: anthropic/claude-sonnet-4-6
• example_output is mandatory
• triggerBody()['text'] is the correct reference in agent flows

The result

Input: meeting minutes with three action items, including one with a vague deadline ("next week").

Output:

Note appended by the model: "Next week" was interpreted as May 8 (Friday) based on the meeting date of May 1, 2026. Please confirm if this is correct.

The model didn't just extract — it resolved ambiguity and surfaced its assumption. That's useful.

What I'd tell someone starting this today

Time and honest assessment

Total setup time: ~3 hours (across both parts)

An engineer would probably finish this in 30 minutes. For a non-engineer, 3 hours. Most of the errors were preventable by reading the API documentation first — which I didn't do carefully enough.

What worked well once running:

• Natural language input → structured JSON output
• Ambiguity resolution with explicit flagging
• Claude Sonnet 4.6 as the processing model (Kawamura International uses Claude Team, so Microsoft picked it up automatically — mildly amusing)

What still needs work:

• The polling loop adds latency. For a single record, StructFlow returns fast — but the Do until loop with 5-second delays adds overhead.
• Error handling is minimal. If the API call fails mid-loop, the flow times out silently.

What's next

MCP connection. Same use case, different integration method. The comparison between REST API and MCP — setup effort, reliability, latency — is the next article.

Kawamura International is a translation and localization company documenting its AI process experiments in public. StructFlow, RefineLoop, RenderOCR — and whatever comes next.