AyDEO is an enterprise platform for bringing Digital Employees into the organization as governed and accountable members of the workforce.

AyDEO defines where they belong, what work they own, which business capabilities they may use, when people must be involved, and how their actions are controlled and audited across enterprise systems.

A Digital Employee, or DE, is an autonomous organizational actor managed by AyDEO.

A DE has:

• a defined job and responsibilities;
• a position within the organization;
• managers and delegated supervisors;
• approved models and business capabilities;
• Cases containing its active work;
• governed authority to act;
• a complete operational and audit history.

A DE is more than a chatbot or background automation. It owns business work and can continue working when no human session is active.

No.

AyDEO does not ask every development team to build its own agent loop, memory system, approval mechanism or orchestration framework. The Digital Employee runtime is part of the platform.

AyDEO is developer-extensible through BFA business capabilities, but business-controlled through its organizational, configuration and governance layers.

Developers build the organization’s governed vocabulary of business actions.

Examples include:

• registering a company car;
• creating a supplier order;
• updating an employee record;
• checking contract compliance;
• requesting a quotation;
• initiating an approved workflow.

Developers focus on domain integrations, security invariants, transactional execution, failure handling and testing.

AyDEO provides the Digital Employee runtime, work context, approvals, human attention, capability enforcement and audit integration.

Behaviour is configured through:

• job description and responsibilities;

• organizational position;

• assigned tools and business capabilities;

• authoritative Case context;

• platform-wide behavioural and security rules.

   

AyDEO does not allow each implementation team to replace the autonomy core. This intentionally sacrifices unrestricted runtime customization in exchange for organizational consistency, security and platform-wide improvement.

The exact responsibilities depend on the organization. Typically, domain experts or business analysts familiar with AyDEO principles define the business capability surface: the governed actions and information access that Digital Employees need to achieve particular goals.

This surface does more than expose business functionality. It shapes how Digital Employees plan, which decisions they may make, what context they can use, and where security or human involvement is required.

Each action defines:

• its business purpose and when it should be used;
• expected inputs and outcomes;
• which inputs may come from the DE and which must come from authoritative context;
• business and security constraints;
• required approval;
• permitted execution and autonomy mode;
• expected evidence and failure behaviour.

Developers—or AI-assisted development teams—implement these capabilities through BFA. Authorized Configuration administrators approve them for platform use, and DE managers assign appropriate approved capabilities to Digital Employees.

BFA, or Backend For Agent, is AyDEO’s governed integration and execution boundary between Digital Employees and enterprise systems.

BFA turns system integrations into normalized, business-meaningful capabilities rather than exposing unconstrained technical APIs. Each governed query or action has an explicit identity, version, schema, purpose, risk, execution mode and consistent outcome contract, allowing AyDEO to discover, approve, assign and invoke capabilities in a uniform way.

A BFA action is designed to be semantically complete: it represents one recognizable business intent and owns the technical behaviour required to carry it out. This can include:

• input validation and preflight fact gathering;
• authoritative Case and business-context checks;
• guards and business invariants;
• approval and execution requirements;
• short-lived multi-system execution steps;
• error and partial-failure handling;
• compensation where appropriate;
• consistent operational and audit evidence.

At runtime, BFA verifies the Digital Employee’s capability, active Case scope and action requirements before consequential execution. It also ensures that confirmation, approval and audit flows integrate consistently with the rest of the AyDEO platform.

The Digital Employee decides which business capability to use and when. BFA determines whether and how that capability may execute safely and consistently.

AyDEO enables a Digital Employee to work toward a defined goal using its available knowledge and approved business capabilities. At each step, the DE chooses an appropriate governed action to move the Case closer to completion.

When the work must follow mandatory stages, deadlines or prescribed rules, the DE can initiate an external workflow through BFA.

When specialist expertise is required, the DE can consult a domain-specific service or agent through BFA and use its result to continue the Case.

Yes.

A specialist agent can be exposed as a governed BFA capability. AyDEO can control:

• which DE may invoke it;
• what information may be shared;
• whether approval is required;
• how the invocation and result are recorded.

The preferred pattern is for a specialist agent to return advice, analysis or a structured artifact. Consequential actions should continue through governed BFA business actions.

No.

Workflow engines are appropriate for predefined, deterministic and long-running processes. AyDEO Cases are appropriate when the next action depends on changing circumstances and Digital Employee judgment.

A workflow can be invoked as one capability within a broader Case. The Case owns the goal and current work; the workflow owns its prescribed subprocess.

No. AyDEO integrates with enterprise IAM—in particular Microsoft Entra ID and Entra agent identity—rather than replacing it.

IAM remains the source of Digital Employee identity and standing entitlements: who the DE is, whether it is active, and which enterprise permissions it may hold. AyDEO uses that identity at runtime and does not invent a parallel authentication system.

What AyDEO adds is the organizational and business context required for autonomous work once identity is established:

IAM / Entra: Who is this Digital Employee, and what may it generally do?
Case: What work is it currently doing, for whom, and under which constraints?
BFA: May this specific action execute now, under that Case and approval state?
These layers complement one another. Entra answers standing identity and entitlement. AyDEO answers how that authority is exercised safely across durable Cases, human attention and governed business actions.

A Case is the durable unit of autonomous business work.

It collects the goal, progress, updates and history as work advances. It also holds the authoritative business context, current working state, commitments and approvals, and who currently holds responsibility—whether a person or a Digital Employee.

A Case is designed to be safely shareable across organizational actors. Humans and Digital Employees can take over or contribute using a bounded, role-appropriate view of the same work, without depending on an original chat session or transferring an entire private transcript.

A Case does not prescribe every step. The Digital Employee determines what should happen next based on the goal, current facts and available capabilities.

Attention items are how AyDEO asks people to participate in autonomous work—and how Digital Employees learn what happened next.

They have two complementary parts:

• a notification that reaches the right person or role;
• when needed, a durable organizational obligation with an attributable owner and a clear lifecycle.

Typical situations include:

• guidance from a manager;
• superior approval;
• additional information from the requester;
• execution that must resume in a user session;
• intervention when a Case is held.

An Attention item progresses through states such as created, seen, processed, approved or rejected. That status is shared with the Digital Employee, which can then reason over the outcome and decide what to do next.

So an autonomous run does not merely “wait for a human.” AyDEO creates a visible obligation for the right organizational actor, records how it was handled, and returns that result into the Case so work can continue safely.

Approval and execution are separate concepts in AyDEO.

Depending on risk and policy:

• a DE may execute autonomously;
• a requester may confirm during an active session;
• a superior may approve asynchronously;
• the requester may need to return and resume execution in their own session / through Chat;
• an approved action may resume autonomously after approval.

This allows AyDEO to express who approves, where execution resumes and which Case authorizes the action independently.

Yes.

When an organization withdraws a capability, changes an assignment, raises risk, or disables a Digital Employee, AyDEO updates the managed runtime so that Digital Employee can no longer obtain the previous right to execute those actions.

Approved business actions remain available only while they are still assigned and current. A disabled Digital Employee, or one whose capability has been withdrawn, cannot continue using the previous execution rights on AyDEO’s managed path.

That keeps operational control close to the business: managers and administrators can adjust what a Digital Employee may do without waiting for a separate redeployment or a long-lived credential to expire.

AyDEO standardizes audit collection across governed BFA execution.

The evidence is linked to the relevant Digital Employee, Case, action, approvals and execution outcome. Organizations do not need each BFA integration team to invent a different audit mechanism.

Operational Case history and forensic audit serve different audiences and access rules.

AyDEO does not claim to reproduce private model reasoning or hidden chain-of-thought.

Instead, it preserves the observable decision context:

• relevant Case facts;
• messages and projections;
• available capabilities;
• events and attention;
• approvals;
• selected actions and inputs;
• BFA guards and execution outcomes.

This enables accountability based on what the DE knew, what authority it had, what it proposed, who approved it and what actually happened.

AyDEO is designed so Digital Employees and their work are not tied to one model provider. Organizations can change models without redesigning Cases, business actions or the organizational structure.

AyDEO does not host the models. Models remain external. AyDEO lists the models it can work with (currently hundreds)  and checks that each candidate meets a minimum capability profile required for Digital Employee use.

From that supported set, Configuration administrators maintain an approved catalogue for the organization, and DE managers assign suitable approved configurations to Digital Employees.

So model choice happens in three layers:

• Platform: which external models AyDEO lists as capable enough to use;
• Organization: which of those models are approved for use;
• Digital Employee: which approved configuration is assigned.

That gives broad provider flexibility while keeping model usage governed and predictable.

Choosing AyDEO means adopting its Digital Employee and organizational operating model, just as adopting a major business platform means adopting its core business abstractions.

That trade-off is intentional—and it buys consistency at scale.

Digital Employees share one operating model for work ownership, approvals, human attention, capability assignment and audit. Platform improvements—security, behaviour, model support or governance—can update all Digital Employees together. Organizations do not maintain thousands of heterogeneous agent runtimes, each with its own planning style, approval logic, identity handling and evidence trail.

AyDEO limits dependency at its boundaries:

• enterprise data remains in source systems;
• deterministic workflows can remain external;
• models are replaceable within platform support and organizational approval;
• specialist services can be integrated through BFA;
• business actions use explicit, versioned contracts.

So the choice is not “free agent architecture versus lock-in.” It is:

Less freedom to redesign every Digital Employee’s autonomy core, in exchange for uniform behaviour, centralized improvement, and far less custom platform engineering.

The alternative is not only a fully custom agent stack. Many organizations also try to assemble autonomy from agent-development frameworks and general enterprise platforms.

Those approaches can provide strong building blocks—identity, workflow, records, tools and human tasks. What they often do not standardize is a single operating model for Digital Employees: one way to own work, assign capabilities, involve people, approve consequential actions, hand work over and produce evidence.

Without that shared model, teams tend to recreate different runtimes, approval patterns, security practices and audit trails. At scale, that becomes a fleet of heterogeneous AI agents rather than a coherent digital workforce.

AyDEO provides one AI operating model for Digital Employees:

• identity and organizational placement;
• durable Cases as the unit of work;
• governed business actions through BFA;
• approvals and human Attention;
• consistent audit and security patterns;
• immediate control over which actions a Digital Employee may execute.

Development teams then concentrate on the business capabilities that distinguish the organization—not on rebuilding the digital-workforce operating layer again and again.

AyDEO remains extensible through BFA, external workflows, specialist services and supported models. It is purpose-built for governed Digital Employees, rather than requiring organizations to assemble that operating model from many separate platform components.

Every AI platform faces this question—including custom-built agent stacks.

AyDEO’s core value is the Digital Employee operating model: how Digital Employees are placed in the organization, own Cases, receive capabilities, involve people, execute business actions and remain accountable. That operating model is deliberately independent of any single model provider, agent framework or workflow engine.

AyDEO is the platform that implements and continuously evolves that model. Because Digital Employees share one runtime, better reasoning approaches, safer execution patterns and proven industry practices can enter the AyDEO roadmap once and improve the whole digital workforce—without forcing every team to re-architect its own agents.

Digital Employee identities, Cases, organizational configuration and BFA contracts remain the stable operating layer. When the platform evolves, existing Digital Employees inherit the improvement.

AyDEO is committed to that evolution: evaluating emerging architectures and adopting proven practices so customers benefit from innovation without rebuilding their digital workforce from scratch.

It does not need to replace every specialist.

A Digital Employee can invoke a domain-specific model, service or external agent through BFA. The specialist supplies analysis or a structured recommendation, while the DE remains accountable for the Case and for how that result is used.

AyDEO governs the invocation and consequential follow-up. It does not claim visibility into an external specialist’s private reasoning or undeclared internal operations.

Yes—where those investments are enterprise capabilities, systems and infrastructure. Not by importing arbitrary external agents as Digital Employees.

A Digital Employee is specific to AyDEO. It runs on the AyDEO runtime and participates in AyDEO’s operating model for Cases, capabilities, Attention, approvals and audit. Existing third-party agents cannot simply be imported and managed as Digital Employees.

What organizations can reuse:

• Entra ID agent identities can be linked into AyDEO Digital Employee lifecycle management;
• Existing APIs, API gateways, MCP servers and workflow engines can be wrapped through BFA as governed business capabilities, with AyDEO-native contracts for schema, risk, approval, error handling and evidence;
• Enterprise data and domain systems remain systems of record outside AyDEO;
• DevOps, infrastructure, network and gateway security standards remain external. AyDEO integrates with them rather than replacing them.

So AyDEO reuses what the enterprise already operates—identity, systems, workflows and integrations—while standardizing the Digital Employee operating model on top. It does not require rebuilding enterprise data or infrastructure inside AyDEO, and it does not turn every existing agent product into an AyDEO Digital Employee.

Not as Digital Employees.

Existing agents keep their own runtimes and control models. AyDEO can reuse their useful capabilities when they are exposed as systems or services and wrapped through BFA. Entra agent identities can also be connected into Digital Employee lifecycle management.