ADMINDescribe the result. Connect the tools that can deliver it.#
YAADMIN is a platform for carrying out tasks through an AI-assisted conversation. IT administration is one use case. Connected services, data tools, scripts and workflows can support reporting, document-related work and business processes as well.
You describe what you want to achieve. YAADMIN can select and coordinate the implemented tools available in your installation, check access, request approval when required and present their results. The scope grows with the connections you provide; the examples on this page are starting points, not the complete set of possible tasks.
Several ways to get work done#
| Connection path | What it contributes | What must be in place |
|---|---|---|
| Native modules | Purpose-built operations, such as reading directory information, checking stock or deploying a software package. | The relevant module, working provider configuration and permissions. |
| MCP services | Tools exposed by a compatible external server, including services beyond the native module catalog. | Successful tool discovery, authentication and suitable discovered operations. |
| Commands and scripts | Work that can be performed through the supported execution environment rather than a fixed list of business actions. | An authorized execution tool, exact target, appropriate account and runtime policy. |
| Agent and Vision | A Windows-to-Core path for session-aware execution and visual interaction with application interfaces. | The appropriate Agent implementation and task/session controls; release and complete visual acceptance limits still apply. |
| Connected workflows, including n8n | A way to delegate a defined sequence to another automation system and use its returned result. | A compatible, configured tool interface exposing that actual workflow; no native n8n module is assumed. |
PowerShell is available through the documented Action1 integration. The inspected YAADMIN Agent implementation also includes PowerShell, CMD, local scripts and executable launch. These paths have different execution contexts and approval rules; they are not interchangeable promises of access to any computer.
Personal tasks and your own PC#
YAADMIN can also be useful at home. You can start with an owned file or spreadsheet, prepare a report, or use a configured supported tool to perform a task on your own computer. A company directory or enterprise workflow is not required for every use case.
Example request: “Summarize this household expense spreadsheet and show the rows behind the totals.” Supply a supported owned file, use its real column names and inspect the calculated results. Files & Tables can work with the stored data; it does not automatically connect to your bank or fetch transactions.
Example request: “Run this reviewed command on my computer and explain the output.” This requires a configured execution connection, a supported command environment and appropriate permissions. The inspected Agent source includes PowerShell and CMD execution, local scripts and executable launch. Follow its documented readiness and approval rules rather than treating a chat request as automatic access to the PC.
For graphical tasks, Agent/Vision is the developing path for observing a program and interacting with its interface inside a bounded task. It is relevant to personal applications as well as organizational systems, but the current Windows/model acceptance and full-screen conformance limits remain the same. No universal application compatibility or completed personal-PC workflow is claimed here.
Work with your files · Agent tools and status · First run
Reports and business information#
Example request: “Find the items in this category, show the stock in the selected warehouse and prepare a table for review.”
With the compatible 1C service configured, resolve the actual warehouse, find relevant items and inspect all available pages. Request stock for the real item identifiers, then review completeness and units. Files & Tables can support further authorized analysis of a stored result and export to Excel. This is a read/report workflow, not permission to change stock or post documents.
Example request: “Summarize this uploaded spreadsheet and show the rows supporting your conclusion.”
Use an owned supported file, inspect its stored table and apply the relevant query or aggregation. Check the underlying rows before sharing the answer. The stored-table query works on that supplied data; it does not automatically refresh every original source system.
1C tools and reporting · Files and Tables
Extend a business process through n8n#
You can extend the overall workflow by connecting an automation system such as n8n through a compatible tool interface. YAADMIN handles the conversation and the exposed operation; n8n handles the workflow that you have actually configured there.
For example, a team could design a workflow that retrieves authorized information from its own services, prepares a report and returns a result. A request such as “Run the connected weekly report workflow with these parameters” is meaningful only when that exact workflow is exposed as a callable tool with a known input schema and suitable access.
- Build and verify the workflow in the external system, including its service connections and credentials.
- Expose the intended operation through a compatible MCP tool server or a trusted implemented YAADMIN module.
- Configure the connection in YAADMIN and inspect the actual discovered tool, required inputs and output behavior.
- Assign access deliberately, especially if the external workflow sends messages or changes records.
- Request the operation in chat, review applicable approval and inspect the returned workflow state or result.
This describes an integration approach, not a verified ready-made n8n connector or a universal setup recipe. A native n8n module, built-in workflow editor and recurring scheduler are not established in the current inventory. A workflow may continue after it is submitted; do not assume a chat stop reverses its external effects.
MCP connections · Custom modules · Automation boundaries
Commands, scripts and application interfaces#
A connected execution tool can run supplied or generated commands and scripts within its supported environment. This can extend work beyond a module's named operations. The real Windows account, target, shell and permissions determine what can run. “Run a command” is not a guarantee that its dependencies exist or that its effects are safe.
Agent with Vision adds a different interaction path: observe an application screen, use permitted mouse/keyboard actions and inspect the next screen. This is relevant to tasks whose interface is graphical rather than exposed through an API.
In the inspected Agent implementation, visual work belongs to a bounded approved task with an exact endpoint, Windows session, allowed applications and time/step limits. Arbitrary shell/system changes require their own authorization. UAC, locked/secure desktops and other-user bypass are not supported by those task grants.
The source contains capture/input and process/session code, but real Windows/model acceptance and complete full-screen reconstruction/model-delivery conformance remain unfinished. A task such as creating a 1C database through the desktop is therefore not presented as a verified end-to-end demonstration.
Agent tools, including CMD · Agent workflow examples · Vision architecture
Concrete examples from documented integrations#
The examples below illustrate source-verified tools with their required connections and permissions. They are not execution transcripts or a promise that every environment will return a successful result.
Available · action1
Connected Windows workstations
“Find connected workstations and check their status.”
- Resolve the organization and endpoint selection
- Read endpoint status
- Review provider-returned details
What you receive
Endpoint identity and status from Action1, or an explicit provider error.
Available · action1
Authorized PowerShell diagnostics
“Run an authorized diagnostic command and summarize its output.”
- Resolve an exact endpoint
- Inspect a suitable library script first
- Evaluate permissions and impact; approve if required
- Run and inspect the returned output
What you receive
Script output or execution errors; a summary must remain grounded in returned evidence.
Available · ad
Directory account lookup
“Find a user account and inspect its directory information.”
- Search with ad.search_users
- Disambiguate the account
- Read with ad.get_user
What you receive
Read-only directory details. No account changes are implied.
Available with service prerequisites · onec
Find information in 1C
“Search for a document or equipment information.”
- Choose the applicable search tool
- Query the compatible 1C HTTP service
- Review returned records or table results
What you receive
Matching service records, subject to the deployed schema; equipment-specific support is not guaranteed.
Available with documented limitations · mcp / Module Manager
Connect a new capability
“Connect an MCP server or install a module and configure tool access.”
- Configure a supported server or validate a module package
- Discover and register tools
- Assign applicable permissions
- Test a permitted request
What you receive
Discovered tools and diagnostic feedback. Connection alone does not establish tool compatibility.
Agent checkpoint — acceptance incomplete · Agent / Core / AI model
Desktop interaction with Vision
“Look at the screen and help me interact with its interface.”
- Agent captures a screen
- Core reconstructs the complete image
- Vision interprets the screen
- Desktop action must pass a verified permission boundary
What you receive
Capture/input and task-scoped tools exist in source; real model/application acceptance and full-screen delivery conformance remain incomplete.
Combine capabilities deliberately#
A useful task can include several steps: identify a record, read information, prepare a table, then request another supported operation. Each step needs a real implementation and an appropriate result to pass onward. Matching display names across services do not automatically establish matching identities.
The AI cannot add an absent tool simply because you describe the desired outcome. Conversely, the documented module list is not a ceiling on the platform: trusted custom modules, compatible external tools and authorized execution paths can extend your installation.
How to adapt an example#
- Choose a real task and identify the connected service or execution path that can perform each step.
- Check the module's readiness, configuration, authentication and exact tool inputs.
- Use real targets or owned files; resolve ambiguous identities instead of guessing IDs.
- Begin with a small information request and inspect the returned source, completeness and errors.
- Before changes or external side effects, review permissions, approval and how to check completion.
- If the outcome is uncertain, inspect state before repeating the request. A submitted job, sent input event or AI explanation is not proof of the intended final result.