Enterprise Agent Orchestration Recovery Leader

The mandate

The executive responsible for the agent platform resigned after an anchor customer disabled production automation when a procurement agent retried an uncertain tool response, created duplicate purchase actions and then inherited an approval permission through a shared connector identity. Separate product squads issued incompatible fixes, leaving the company unable to reconstruct which plan, memory state and credential governed a consequential action across long-running workflows.

The interim must be in Bengaluru within fourteen days and will carry executive platform authority for eighteen months. A permanent search begins in month ten, after the runtime has completed two stable quarterly releases; the final eight weeks are reserved for joint release, customer and incident decisions, and the temporary appointment ends on schedule even if a deferred product feature remains unfinished.

Handover is achieved when every privileged action is bound to a named agent, policy version, scoped identity and idempotency record; interrupted plans can be resumed or reversed without duplicate effect; and three anchor deployments have each completed ninety days without an unresolved severity-one orchestration event. The successor must independently replay a sampled incident, chair a go/no-go review and accept the open architecture exceptions and customer recovery ledger.

The interim may freeze connectors, stop agent classes, set platform reliability thresholds, reorganise incident command, contract temporary specialists and allocate up to ₹28 crore from the approved recovery budget. Board consent is required to retire a contracted product line, settle customer claims, alter the enterprise risk appetite or exceed that envelope; the interim may not make permanent executive appointments, renegotiate commercial warranties or approve use of customer data for model training.

Foundation-model research, the corporate ERP replacement, sales-territory design and feature work unrelated to action control are excluded. The seat owns evidence and operating boundaries at their interfaces but does not select the company’s base-model portfolio, lead general cost reduction or absorb customer-specific implementation backlogs that have no orchestration defect.

Why this seat is open

The incident exposed a runtime assembled around successful demonstrations rather than durable action semantics under retries, partial failure and changing permissions. Product, identity and delivery leaders each control one layer but no remaining executive can impose a cross-platform recovery sequence while also adjudicating anchor-client pressure. The board has separated restoration authority from the roadmap until a permanent platform leader can inherit a tested control system.

What you will own

• Freeze and classify existing agent workflows by action consequence, reversibility, credential reach, memory dependency and exposure to ambiguous tool responses.
• Establish an orchestration contract for identity binding, idempotency, compensation actions, plan state, human approval, timeout behaviour and versioned policy evaluation.
• Decide the controlled reactivation sequence for connectors and agent classes using witnessed failure injection rather than customer urgency or demonstration success.
• Reconstruct the anchor incident across prompts, plans, memory writes, credential exchanges, retries and downstream system commits, preserving a defensible causal record.
• Integrate runtime traces into one action ledger that customer operations can query from business outcome back to model, policy, identity and tool response.
• Reset release governance so architecture exceptions expire, cross-layer tests block promotion and customer-specific patches cannot bypass the shared control plane.
• Induct the permanent leader through three live decisions covering an incident, a connector release and an anchor expansion, recording transferred authorities and unresolved trade-offs.

Candidate qualifications

• Held CTO, platform vice-president or enterprise architecture authority for an agentic-automation, workflow or distributed-systems product operating consequential customer actions.
• Recovered a stateful orchestration platform from duplicate execution, partial commit or credential propagation failure and can evidence the design change under production load.
• Designed idempotency, saga compensation, durable execution, policy enforcement and distributed tracing across heterogeneous enterprise tools rather than a single demonstration stack.
• Governed machine-generated plans whose permissions and memory evolved during execution, including reliable abstention and human intervention at irreversible steps.
• Faced enterprise customers during a material platform failure and converted incident evidence into staged restoration, contractual confidence and measurable service stability.
• Completed an executive succession after reorganising product, reliability, identity and implementation teams around a shared technical control model.

Non-negotiables

• Available within fourteen days for an exclusive Bengaluru-based assignment, including monthly Pune travel and quarterly attendance at the Singapore or Dallas anchor site.
• Will halt privileged automation when action identity, replay safety or reversibility cannot be evidenced, regardless of customer launch or revenue timing.
• Has personally operated distributed orchestration at enterprise scale; prompt engineering, chatbot delivery or prototype-only agent experience is insufficient.
• No undisclosed equity, referral payment or advisory role with a foundation-model, orchestration, identity or observability vendor being considered for recovery.

1. 49 words maximum. State your notice position, earliest Bengaluru start and any obligation incompatible with an exclusive eighteen-month recovery seat.
2. 49 words maximum. Describe a duplicate or partially committed automated action you recovered, including the failed orchestration assumption and production proof of correction.
3. 49 words maximum. Which evidence would you require before re-enabling an agent that can invoke a privileged enterprise connector after an uncertain response?