Architecture - Idemeum Docs
Documentation Index
Fetch the complete documentation index at: /llms.txt
Use this file to discover all available pages before exploring further.
How Endpoint Care works
Every user IT request follows the same lifecycle:
1 · Understand
Skill match?
2 · Plan
Triage
diagnose · categorize · route
3 · Check · security gates
4 · Execute
Preview + consent
5 · Report · ticket with full trail
- Understand - the employee types a request (or clicks a quick action). The agent interprets the intent and selects the matching skill. If nothing matches, the run becomes a triage run.
- Plan - the agent reads the skill and produces an explicit, ordered plan of tool calls for this specific goal.
- Check - the plan passes through the guardrail pipeline: intent screening, plan validation against the skill’s allowed tools, and central policy evaluation.
- Execute - steps run one at a time on the device. Diagnostic steps are read-only. Corrective steps pause at gates: a preview of exactly what will change, and a consent prompt the user must approve.
- Verify and report - the agent confirms the outcome (including asking the user), then produces a summary. Every run, resolved or not, is recorded as a ticket with the full diagnostic trail.
Major components
- Desktop agent - the app is on each computer: chat UI, local diagnostics and fixes, enforced guardrails. Installs with one command.
- Skills - natural-language playbooks, one per problem type (disk cleanup, email repair, VPN). Each defines its steps and allowed tools. IT can add custom skills and toggle any skill from the cloud.
- Tools - deterministic, code-reviewed functions that do the actual work (scan disk, flush DNS, repair keychain). The AI chooses which to use; it never runs raw commands.
- Guardrails - the checks between request and action: intent screening, plan validation, policy, and per-step consent and previews. Enforced by the system, not the model.
- Triage - the safety net. Unresolvable issues are diagnosed, categorized, and routed with evidence. No request dead-ends.
- Cloud console - central skill management, policy, analytics, and audit.
- Integrations - ticketing systems, plus Slack and Teams entry points.
Terminology
| Term | Definition |
|---|---|
| Skill | A natural-language playbook for one class of problem. Defines when to run, the steps, the allowed tools, and edge-case handling. |
| Tool | A deterministic, code-reviewed function that performs one action on the endpoint. Tools carry risk metadata (risk level, destructive or not, consent required). Skills reference tools; they are never the same thing. |
| Run | One end-to-end execution: request, plan, gated execution, verification, and report. |
| Plan | The explicit, ordered list of tool steps the agent generates from a skill for a specific request, before anything executes. |
| Gate | A point where execution pauses for a human. Types: consent (approve a risky action), preview (see exactly what would change before it does), acknowledgment (confirm an out-of-band step is done), and intake form (provide structured details). |
| Allowed tools | The fixed list of tools a skill may use. The agent cannot reach outside it. |
| Risk level | A tool’s declared impact rating. Higher risk triggers stronger gating. |
| Triage | The fallback flow for issues no skill can fix: diagnose, categorize, prioritize, and route with evidence. |
| Resolution | A run whose fix was confirmed, by verification or by the user. |
| Escalation | A run handed to IT with the diagnostic bundle attached, either because triage routed it or because fixes did not resolve it. |
| Diagnostic bundle | The device evidence attached to a ticket: device context, relevant diagnostics captured at the moment of the problem, steps already taken, and the conversation. |
| Quick action (pill) | A one-click shortcut in the chat UI that starts a common skill (“Fix Email”, “Free up space”). |
| Audit trail | The complete cloud-side record of a run: the plan, every gate decision, every tool result, and the outcome. |