Orkes demo request: what should we prepare for the call (use cases, security requirements, current stack)?

Most teams treat an Orkes demo request as “just another vendor call” and show up underprepared. That usually leads to a generic walkthrough instead of a session tuned to your real use cases, security requirements, and current stack. A bit of prep turns the demo into an architecture working session that helps you quickly see whether Orkes is the right orchestration layer for you.

Quick Answer: Before your Orkes demo, prepare 2–3 concrete workflows or agentic use cases, a high‑level view of your current stack, basic security/compliance requirements, and clarity on your success criteria and timeline. This lets the Orkes team tailor the demo to your environment and production constraints.

Frequently Asked Questions

What should we have ready before an Orkes demo request?

Short Answer: Come with 2–3 priority workflows or AI agent use cases, a sketch of your current architecture, and your top security/compliance needs and success metrics.

Expanded Explanation:
The most productive Orkes demo calls look less like a product tour and more like a design review. To get there, you want a clear picture of which processes are hurting today (missed SLAs, brittle integrations, untraceable agent actions), how your services are wired together, and what guardrails your security and platform teams require. That context lets the Orkes team show you how to map those flows into durable workflows, human-in-the-loop steps, and MCP-governed tools, instead of spending 45 minutes on generic slides.

If you’re unsure where to begin, pick your most painful POC‑to‑production gap: the agent that works in a demo but can’t be trusted in production, or the cross‑service process that always breaks during incidents. Use that as your anchor use case for the call.

Key Takeaways:

• Bring real workflows and agentic scenarios, not just “we want orchestration.”
• Be ready to explain current pain: failures, debugging effort, and SLA risks.

---

How should we define and share our use cases for the Orkes demo?

Short Answer: Describe each use case as a sequence of steps across services, agents, and humans, plus what “done” means and where things typically fail.

Expanded Explanation:
For Orkes, a “use case” becomes a workflow: a definition (via UI/JSON/SDK) plus workers/tasks (your services, agents, APIs, humans) plus execution controls (retries, timeouts, state persistence, compensation). On the demo call, you don’t need a full workflow spec—but you should be able to walk through the happy path and common failure modes.

Focus on one or two representative flows, such as:

• An AI agent evaluating a request, calling multiple internal APIs, and requiring human approval before a risky action.
• A cross‑service process (e.g., customer onboarding, order fulfillment, KYC, incident response) that today is stitched together with hand‑rolled scripts and manual handoffs.

For each, outline the steps, the systems involved, and what goes wrong in production (timeouts, retries missing, no audit trail, no way to pause for approvals).

Steps:

1. List 2–3 candidate workflows or agent flows that matter for SLAs or revenue.
2. Write a simple step‑by‑step sequence for each: “Agent calls LLM → hits service A → waits on external event → requires human approval → calls service B.”
3. Note pain points per step: where errors occur, where you lack observability, and where you need approvals, RBAC, or audit logs.

---

What details about our current stack are useful for an Orkes demo?

Short Answer: Share your core languages, protocols, data/event systems, deployment targets, and how you currently orchestrate cross‑service flows (if at all).

Expanded Explanation:
Orkes fits into your existing stack; it doesn’t replace your services. For a useful demo, the team needs to understand how your services expose capabilities today and what operational tools you rely on. This helps them show concrete integration points—SDKs, HTTP/gRPC tasks, event consumption, MCP Gateway—and how to wire Orkes into your CI/CD and monitoring.

Be ready to describe:

• Runtime stack: languages (Java, Python, Go, C#, Node/TypeScript, etc.), frameworks, and whether services are containerized.
• Integration patterns: HTTP/gRPC APIs, message queues (e.g., Kafka), cron jobs, scripts, existing orchestrators or schedulers.
• Observability stack: Prometheus, Grafana, Datadog, custom dashboards, log aggregation.
• Hosting: AWS/Azure/GCP vs on‑prem; whether a customer‑hosted deployment might be required.

Comparison Snapshot:

• Option A: Minimal stack detail: “We use microservices.”
• Option B: Concrete stack detail: “We have ~40 services in Kubernetes, mostly Java and Node, exposed via HTTP; Kafka for events; Datadog for monitoring; and a few cron-based batch jobs.”
• Best for: The more concrete “Option B” is best for getting a tailored demo that shows specific SDKs, task types, and deployment topologies.

---

How should we prepare our security and compliance requirements?

Short Answer: Clarify your data sensitivity, compliance frameworks (e.g., SOC 2, PCI, HIPAA), RBAC model, and where you may need customer‑hosted or regional deployments.

Expanded Explanation:
Orkes is built for enterprises that care about security posture and governance, but your constraints matter. If your security team needs particular attestations, network boundaries, or auditability guarantees, surface those early. The Orkes team can then explain SOC 2 Type II compliance, RBAC controls, audit logs, secrets handling, and hosting options (Orkes‑hosted vs customer‑hosted on your cloud) in the context of your actual requirements.

Think about:

• Data types involved in the workflows (PII, financial data, health data, internal-only).
• Compliance: existing mandates (SOC 2, PCI‑DSS, HIPAA, GDPR, regional data residency).
• Access control: how you think about least privilege, SSO/IdP integration, and who should be allowed to change workflows, secrets, and MCP tools.
• Hosting constraints: whether certain workflows must run within your own cloud account or on‑prem, vs being acceptable on multi‑tenant SaaS.

What You Need:

• A short list of security/compliance must‑haves (e.g., SOC 2 Type II, audit logs, fine‑grained RBAC, secrets isolation).
• A preliminary view on deployment preferences (Orkes‑hosted vs customer‑hosted in your cloud, region requirements).

---

How do we align the demo with our strategic goals and success criteria?

Short Answer: Decide in advance what “success” looks like—faster POC‑to‑production for agents, reduced on‑call load, SLA protection, or retiring brittle glue code—and share your timeline.

Expanded Explanation:
Orchestration is the missing layer that moves AI agents and distributed workflows beyond demos. The Orkes demo is your chance to test whether that layer can actually close your execution gap: governed runs, consistent failure handling, replayable traces, and auditability.

Before the call, align internally on:

• Outcomes you want in the first 3–6 months (e.g., “productionize our support agent,” “reduce order-workflow incidents,” “standardize human approvals for risky actions”).
• Metrics that matter (MTTR, number of incidents, time spent debugging, time to ship new workflows, SLA adherence).
• Constraints: budget, headcount, and whether you need up to 99.99% availability SLAs out of the gate, or if you’ll start in the Developer Playground (with no SLA, limited scalability, and variable performance—not for production).

Share these with the Orkes team so they can focus on the right product surfaces: Agentic Workflows and LLM Tasks, Human Tasks for approvals, MCP Gateway for safe agent tools, Advanced Metrics for monitoring, and Git-like versioning for safe rollout and rollback.

Why It Matters:

• Clear success criteria let you evaluate Orkes as a production layer, not just a cool demo.
• A defined timeline (POC vs production) guides whether you start in the free playground or move quickly to an enterprise deployment with SLAs and support.

---

Quick Recap

To get real value from your Orkes demo request, walk in with substance: 2–3 concrete workflows or agentic use cases, an honest map of your current stack, and upfront security and compliance expectations. Pair that with clear business and operational outcomes—closing the POC‑to‑production gap for agents, reducing on‑call pain, and protecting SLAs—and the call becomes a working session on how to model your flows as durable, observable, and governable workflows with humans, agents, and services all in the loop.

Next Step

Get Started