Kognitos vs Microsoft Power Automate

Kognitos

Kognitos has a self-serve free workspace, a public OpenAPI file and a hosted MCP server with OAuth 2.1 and scoped, expiring tokens. The 21 October AI Employees and Context Graphs are in preview for existing customers only, and their REST and MCP access isn't documented, so an outside agent can reach the automation platform but not the new parts.

Microsoft Power Automate

Cloud flows in a solution are rows an agent can read and write through the Dataverse Web API under Entra ID OAuth and security roles, with published limits and a 99.9 per cent SLA. Flows under My flows can't be managed in code, a flow's body is one hand-built JSON string, and setup needs a tenant administrator.

Kognitos

1. Don't plan on Context Graph or AI Employee calls. Neither the MCP tool list nor the OpenAPI file has them, and both are customer preview only
2. Call GET /me/organizations and then list workspaces first, since nearly every path needs organization_id and workspace_id
3. Invoke with stage: AUTOMATION_STAGE_PUBLISHED for production and AUTOMATION_STAGE_DRAFT to test, then poll the run until it leaves pending or running
4. Treat a waiting run as a question for a person. Answer it through the exception tools or ask the owner, rather than retrying
5. Use OAuth with callback port 3777 for the MCP server. Another port can fail with a callback URL mismatch

Microsoft Power Automate

1. Filter workflows on category eq 5 for cloud flows, and add $select, because clientdata holds the whole definition
2. Flows created through the API start with statecode 0 (off). The docs say to turn the flow on before use
3. Put the flow in a solution first. Flows that sit only under My flows are outside the supported API
4. On 429 wait the Retry-After seconds. Reads of flowruns count against the daily Power Platform request allowance
5. Treat an HTTP trigger URL with sig= as a secret, and prefer the tenant or named-user trigger modes with a bearer token for https://service.flow.microsoft.com/