Frequently Asked Questions

Shogun AFM is an Agent Fleet Management platform for running, coordinating, and governing AI agents.

It is designed for organizations that want more control over how AI agents operate across local machines, internal tools, browsers, APIs, models, and third-party agent ecosystems.

Shogun executes the agents. Gensui governs the fleet.

AFM stands for Agent Fleet Management.

The concept is simple: one agent can be useful, but organizations will increasingly need to manage many agents across different machines, tools, workflows, and environments.

Shogun AFM is designed to support that future.

Shogun is the agent execution and orchestration layer. It runs agents, tools, browser automation, desktop automation, memory, workflows, and local execution logic.

Gensui is the governance and control layer. It supervises Shogun instances, manages fleet visibility, policy, security posture, shutdown controls, auditability, and enterprise governance.

In short: Shogun runs the agents. Gensui governs the fleet.

Shogun AFM includes agent-building and orchestration capabilities, but it is broader than a simple agent builder.

It is designed as an operating environment for AI agents, including agent execution, tool use, browser automation, desktop automation, memory, workflow orchestration, local safety controls, fleet governance through Gensui, and A2A interoperability with other agent systems.

Not directly. Shogun AFM is not positioned as a simple replacement for Microsoft Copilot. Microsoft Copilot is deeply integrated into the Microsoft ecosystem.

Shogun AFM is better understood as an independent and hybrid agent control layer.

It can be relevant for organizations that want more local control, model flexibility, self-hosted or hybrid deployment options, browser and desktop automation, agent fleet governance, reduced dependence on a single vendor ecosystem, and interoperability with other agent platforms through A2A.

Shogun AFM can exist alongside Microsoft, Salesforce, Google, ERP, and other enterprise agent systems.

Shogun AFM addresses a core enterprise challenge: as AI agents become more capable, companies need to know which agents are running, what they are allowed to do, which tools they can access, whether they can be stopped, whether their actions can be audited, how they interact with other agents, and how to avoid uncontrolled or vendor-locked agent environments.

Shogun AFM provides a structure for running agents with control, visibility, and governance.

Yes. Shogun can run as a standalone local system without Gensui.

In standalone mode, Shogun uses local safety controls such as ToolGate, Komainu, local sessions, local configuration, and local audit logging.

This makes Shogun useful for personal use, experimentation, local pilots, and smaller controlled deployments.

When Shogun is connected to Gensui, it becomes part of a governed fleet.

Gensui can provide central visibility, agent enrollment, fleet discovery, policy management, remote shutdown controls, central audit, enterprise governance, security posture management, and optional enterprise identity integration.

Standalone Shogun is locally safe. Gensui-connected Shogun is enterprise governed.

Shogun AFM is designed as an IT-owned deployment. Once installed, the organization can inspect, adapt, modify, and maintain the code for its own internal use, subject to the applicable license terms.

This gives the organization operational ownership and avoids dependency on a closed black-box vendor platform.

Alpha Horizon can provide implementation guidance, architectural support, or advisory assistance where agreed.

Shogun is designed to fail safely. If an agent, tool, policy check, or session fails, the affected operation should stop rather than continue uncontrolled execution.

Standalone Shogun can be stopped locally. Ronin sessions can be ended by the user. Komainu can pause active execution. Gensui can remotely pause or shut down agents through central controls.

Because the system is inspectable and adaptable, internal IT teams can diagnose, repair, disable, or extend the system as needed.

Yes. Shogun AFM is designed around familiar technologies and patterns, including Python, FastAPI, React, SQLite/local database patterns, Qdrant memory where used, API-based tool integration, local configuration files, and readable policy and preset structures.

The goal is not to hide agent behavior behind a black box. The goal is to make agent execution understandable, inspectable, and controllable by IT.

Shogun is designed for local, self-hosted, and hybrid deployment patterns.

Depending on configuration, it can use local models, API-based models, local tools, browser automation, desktop automation, internal APIs, external services, and Gensui fleet governance.

This allows organizations to choose the level of local control, cloud dependency, and integration depth that fits their environment.

Shogun should not rely on trust alone. The safety model is based on controlling what agents can actually do through tools.

Agents may reason, plan, and process information, but real-world action happens through tools such as browser, file, terminal, API, email, or desktop-control tools.

Shogun uses a local safety layer called ToolGate to check tool use. The basic flow is: Agent wants to use a tool → ToolGate checks mode, risk, policy, and parameters → Action is allowed, confirmed, or blocked.

This prevents agents from freely performing high-risk actions without control.

ToolGate is Shogun's local tool-safety middleware. It checks tool calls before they execute.

ToolGate can evaluate which tool is being used, the tool's risk level, the current mode, the active policy, the target path/URL/system, whether the action is destructive, whether it is inside the approved workspace, whether it requires confirmation, and whether it must be blocked.

ToolGate is intended to run silently in the background for normal safe actions and only interrupt when necessary.

No. ToolGate should not stop normal agent work. It is designed to allow safe actions silently and only intervene when the agent attempts something risky, destructive, blocked, or outside policy.

For example: reading a webpage is allowed silently, searching memory is allowed silently, writing a report to an approved workspace is allowed or lightly checked, running a terminal command requires confirmation, deleting a folder is blocked or requires confirmation, entering credentials is blocked by default, and making a payment is blocked by default.

The goal is not to slow agents down. The goal is to stop unsafe actions at the point where they could cause real-world impact.

Enterprise governance should be policy-based, not popup-based. In an enterprise setup, policies are defined upfront. Agents can then work normally inside approved boundaries.

For example, a procurement research agent may be allowed to read supplier documents, search public websites, extract supplier data, and write draft reports. It may require approval to send supplier emails, update ERP records, upload documents, or submit forms. It may be blocked from deleting files, entering credentials, changing payment data, running terminal commands, or accessing HR or finance folders.

The agent is not interrupted while working inside policy. It is only interrupted when it tries to cross a protected boundary.

Komainu is Shogun's safety pause mechanism. It acts as a kill switch for active elevated execution.

Komainu can be triggered when the user presses pause, a Ronin session expires, the agent attempts a blocked critical action, the agent repeatedly attempts denied actions, mass deletion is attempted, credential entry is attempted, a tool-call limit is exceeded, or suspicious behavior is detected.

When Komainu is triggered, active elevated execution stops and further tool calls are blocked until the user or administrator intervenes.

Harakiri is the stronger shutdown control used from Gensui.

Where Komainu pauses or stops active execution locally, Harakiri is intended for central shutdown actions across agents, groups, instances, or fleets.

Gensui can use Harakiri to stop one agent, a group of agents, one Shogun instance, a group of Shogun instances, or the full fleet.

This gives administrators emergency control over autonomous agent activity.

Yes, if implemented with parameter-aware ToolGate rules. Delete authority should never mean that an agent may delete anything freely.

For destructive actions, Shogun should check what is being deleted, how many items are affected, whether the target is inside the approved workspace, whether the delete is recursive, whether the action is reversible, whether the files were created by the current task, and whether the target is a protected folder.

Recommended defaults include: permanent delete is blocked by default, recursive delete is blocked by default, delete outside workspace is blocked, mass delete is blocked and triggers Komainu, delete of generated temp files goes to Shogun trash/quarantine, and deleting business files requires confirmation.

Shogun should treat external content as untrusted data. External content includes webpages, emails, PDFs, documents, Slack messages, CRM notes, browser content, and uploaded files.

A webpage or document may contain malicious instructions. Shogun should treat that as content to analyze, not as an instruction to obey.

Prompt injection may influence the model's reasoning, but it should not be able to bypass ToolGate, policy, Komainu, or Gensui governance.

The core principle is: The model can think. Shogun controls action.

Yes. Shogun should use a brokered credential model. Agents should not directly receive passwords, API keys, OAuth tokens, ERP credentials, database credentials, or service account secrets.

Instead, the credential is stored and managed by Shogun or the organization's approved credential mechanism. The agent requests an approved tool action. ToolGate checks whether the action is allowed. Shogun performs the action through a controlled tool or credential broker. The agent receives the result, not the secret.

This reduces the risk of secrets being leaked, copied, or misused by an agent.

In standalone mode, Shogun can use local safety and local configuration.

In Gensui-connected enterprise mode, Shogun can be extended with enterprise identity patterns such as Keycloak, OAuth2 token exchange, SPIFFE/SPIRE workload identity, short-lived scoped tokens, role-based access control, and user/group-based governance.

These features belong primarily in the Gensui enterprise governance layer.

Yes, but access should be controlled. The recommended pattern is not to give the agent raw system credentials.

Instead, internal systems should be accessed through approved tools, APIs, or controlled broker patterns. For example: Agent requests supplier data → ToolGate checks policy → Approved ERP read tool executes the request → Agent receives the result.

Write actions should normally require stronger control, such as confirmation, role-based approval, or Gensui policy.

Yes. For business pilots, a read-only-first posture is recommended.

This means the agent may read documents, read webpages, analyze information, summarize findings, extract data, create draft reports, and write to a dedicated workspace.

But it may not silently delete files, send emails, update ERP/MRP records, enter credentials, run terminal commands, or modify business-critical systems.

This is a practical way to prove value while minimizing operational risk.

Ronin is Shogun's higher-authority automation posture. It allows agents to interact with browser or desktop environments depending on configuration.

Ronin is powerful, but it must be controlled carefully. The recommended split is: Ronin Browser Mode for browser-only automation through Mado/Playwright, and Ronin Desktop Mode for full desktop-control automation under strict supervision.

Mado is Shogun's browser automation capability. It allows agents to interact with browser sessions, read pages, navigate websites, and perform browser-based tasks.

Mado is especially useful for systems that do not expose clean APIs but can be accessed through a browser.

Ronin can be useful in enterprise contexts, but it must be governed properly.

Ronin Browser Mode is generally easier to control because browser actions are more structured. Ronin Desktop Mode is higher risk because mouse and keyboard control can potentially affect many local applications.

Recommended enterprise defaults: Ronin Browser Mode is allowed with policy. Ronin Desktop Mode is supervised, time-limited, audited, and protected by Komainu. Credential entry is blocked by default. Terminal execution requires confirmation. File deletion is blocked or requires confirmation. System changes are blocked by default.

Ronin should be presented as controlled automation, not unrestricted desktop control.

Ronin Browser Mode may be suitable for controlled background tasks, depending on policy.

Ronin Desktop Mode should not be treated as unrestricted background automation. Desktop-control agents should operate with a visible active session indicator, time-limited session, Komainu enabled, clear policy boundaries, audit logging, and confirmation for risky actions.

Yes. Shogun can log important agent and tool activity through EventLogger. In standalone mode, this provides local audit visibility. In Gensui-connected mode, audit events can be collected centrally across the fleet.

Audit events can include tool requested, tool executed, tool blocked, confirmation requested/approved/denied, Komainu triggered, Ronin session started/ended, policy violation, and remote shutdown command.

Gensui can provide a central view of agent activity across multiple Shogun instances.

This may include active agents, enrolled Shogun instances, active policies, blocked actions, tool usage, approval events, Komainu triggers, Harakiri shutdowns, Ronin sessions, fleet health, and policy violations.

This helps organizations understand not only what agents produced, but also what agents attempted to do.

Yes. In Gensui-connected mode, policy decisions should be traceable.

A tool action can be logged with information such as agent ID, Shogun instance, user/session, tool name, risk level, action target, policy source, decision, timestamp, and approver if relevant.

This supports operational transparency and governance.

A2A stands for agent-to-agent communication. It allows agents from different systems or platforms to communicate, coordinate, or exchange tasks through a structured protocol.

For Shogun AFM, A2A is important because enterprise AI will not exist in one closed ecosystem. Companies may use Microsoft agents, Salesforce agents, internal agents, ERP agents, custom Python/FastAPI agents, local agents, and cloud agents.

Shogun can use A2A to participate in a hybrid agent environment.

A2A allows Shogun to connect with other agent ecosystems instead of trying to replace them.

This supports a more realistic enterprise strategy: Use Shogun where independent, local, custom, or governed agent execution is needed. Connect Shogun to other enterprise agents where appropriate.

This makes Shogun AFM more useful in mixed enterprise environments.

The strategic direction is that Shogun should be able to connect with external agent ecosystems through A2A or integration layers.

The goal is not to force all agents into Shogun. The goal is to allow Shogun to operate as an independent control and execution layer in a broader agent landscape.

Shogun is intended to support model flexibility. Depending on configuration, it can use local models, API-based models, open-weight models, commercial models, and specialized models for specific tasks.

This helps organizations avoid overdependence on one model provider.

Agent workflows may become dependent on the model layer. If one model becomes unavailable, restricted, too expensive, too slow, or unsuitable for a specific task, the workflow may be affected.

A model-agnostic approach gives organizations more strategic freedom. It allows them to choose the best available model for each task without rebuilding the entire agent operating model.

Not necessarily. Shogun can be deployed in local or self-hosted configurations.

Whether data leaves the organization depends on the selected model provider, tool configuration, API usage, deployment architecture, data policies, Gensui configuration, and integration design.

Organizations can design Shogun deployments to keep sensitive data local or route only approved data to external services.

Shogun AFM should be understood as open-code or source-available under its applicable license, not necessarily as a traditional open-source project.

Users should review the license terms directly. The intended model is that organizations can download, inspect, use, and adapt the code for their own internal use, while restrictions may apply to redistribution, resale, or repackaging.

Yes, subject to the applicable license terms. The intended use model allows organizations to alter and adapt the code for their own internal needs.

This may include adapting tools, adjusting policies, adding integrations, fixing issues, aligning with internal IT standards, connecting to internal systems, and customizing workflows.

No, not unless the license explicitly allows it.

Shogun AFM is intended to be free to use and adaptable for internal use, not freely repackaged or resold as another vendor's product. Organizations should review the license before redistribution, commercial packaging, or external resale.

Shogun AFM is especially relevant for organizations that want to explore agentic AI while retaining control.

Potentially relevant organizations include mid-sized industrial companies, operational businesses, companies with legacy systems, companies with browser-heavy workflows, companies with internal process automation needs, companies exploring local or hybrid AI, companies concerned about vendor lock-in, and companies wanting custom AI agents outside standard SaaS ecosystems.

A good first pilot should be useful but low-risk. Recommended starting points include document analysis, supplier research, competitor research, report generation, data extraction, internal knowledge assistant, process documentation, browser-based information gathering, and drafting outputs for human review.

Avoid starting with autonomous ERP updates, payment-related workflows, credential-heavy workflows, file deletion, production system changes, or unsupervised desktop control.

Traditional RPA often automates predefined steps in deterministic workflows. Shogun AFM is designed for agentic work, where agents can reason, use tools, search, summarize, adapt, and coordinate tasks.

However, for enterprise use, Shogun should still borrow important lessons from RPA: clear boundaries, auditability, exception handling, approval points, safe failure behavior, and controlled system access.

Shogun AFM is not "uncontrolled AI automation." It is a governed agent execution environment.

Many agent frameworks focus on building or running individual agents. Shogun AFM focuses on the broader operating environment: agent orchestration, local execution, browser automation, desktop automation, memory, tool governance, fleet control, shutdown control, A2A interoperability, and Gensui governance.

The focus is not only on creating agents, but on managing them responsibly.