Frequently asked questions

Product positioning

How is this different from a chat-style coding assistant?

A chat assistant optimises the quality of a single interaction. SkyMythos optimises whether one piece of R&D work can be explained, audited, replayed and handed off by an organisation.

The difference is concrete. Execution inputs are frozen rather than drifting with the session. Multiple nodes are independent sessions rather than one long conversation. Completion is proven by artefacts and unit gates rather than asserted in natural language. A failure keeps its lineage and can be recovered from a defined boundary. Long-lived cognition enters a reviewable knowledge space instead of scattering across session history.

Is it a CI/CD system?

No. It covers the span from requirement and design to code delivery, and works alongside existing code hosting, CI/CD and release systems. It does not take over build clusters, and it does not take over production release.

Is it an agent framework?

No. It is a control plane: it owns identity, versions, policy, sandbox lifecycle and delivery. The agent runtime is a replaceable component, integrated through versioned adapters.

Why not a large DAG canvas?

Because running tasks and their sessions are the primary working surface. The dependency graph exists to explain the process, and is expanded on demand. Making the canvas the centre of the product would suggest that orchestration is itself the goal, when the goal is a deliverable engineering result.

Deployment shape

Is there a SaaS option?

The product is designed on the premise of private deployment only. The core control plane, sandbox, model access, artefacts and telemetry paths all run independently inside the customer environment, with no dependency on an external managed service.

That means every state authority must be deployed inside the customer network.

What is the minimum required?

A container runtime, a model gateway, and PostgreSQL and S3-compatible object storage for production. The Kubernetes path additionally needs a cluster and the agent sandbox prerequisites installed in advance.

Can we use our own model gateway?

Yes — that is the design goal. The platform manages gateway addresses and model catalogues by capability class, and supports multiple providers and protocols. Model fallback is a capability internal to the gateway and is transparent to a flow.

Does it need internet access?

The critical path has no dependency on the public internet. Model calls egress to the gateway you configured yourself. Skills and extensions can come only from the local registry, and the sandbox is forbidden from fetching capability code from the public internet at start-up.

Can it be used without a model?

No. The platform ships no built-in model and provides no rule-based fallback.

Security and governance

Can a prompt or a skill serve as a security boundary?

No, and that is an explicit architectural position. Credentials, tools, network access and high-risk side effects must be constrained by platform policy.

Concretely: a task receives only the credentials injected by a minimal recipient; the main agent process does not hold extension credentials directly; task secrets are deleted as soon as the components that need them are ready; the sandbox is forbidden from pulling code from the public internet at start-up; and an agent running in a Workspace does not fall back to personal credentials.

Are code and credentials sent anywhere?

Code is processed only inside the task sandbox, and artefacts are archived to object storage you configure yourself. Credentials are stored encrypted and injected at runtime by reference through environment variables; plaintext is never written to a configuration file, a specification, an event or a log. Session bodies exist only for the lifetime of the sandbox by default, and do not enter the business database.

An enterprise can enable separately encrypted session archiving and retain it under policy.

Can an administrator see my personal credentials?

No. Access tokens and secrets are stored encrypted; an administrator cannot read them in plaintext and the API does not echo them.

What do audit records contain?

Publishing, withdrawal, tag moves, task resolution, sandbox materialisation, connection readiness and rework refresh enter the security audit. Secrets, full prompts and session bodies do not.

Running and failures

Can a task continue from where it was interrupted?

It can be resumed, within a defined boundary. Inside an available sandbox, a new execution generation can be created from an already-started node that the user or a gate decision selects.

What happens if the whole sandbox is lost?

The task fails. There is no cross-sandbox recovery — dependency graph state, sessions, artefacts and Git worktrees live in the same failure domain, and that is a deliberate design trade. The alternative would require a distributed state machine, and at this stage the complexity does not pay for itself.

Why is the sandbox not released while waiting for user input?

Because the dependency graph state lives inside the sandbox. Releasing it would lose the execution lineage. This limitation is known, and changing it would require a new architectural decision.

What happens when a model returns an empty response?

A bounded number of recovery sessions is started under a backoff policy. Once those are exhausted, an explicit node failure is retained, so it can be rerun individually after the model or connector is updated. An empty response is never disguised as completion.

Can a required node be skipped?

No. Skipping a required node breaks the integrity of the artefact contract, leaving downstream to consume something that was never produced. That is precisely the class of problem this product exists to remove.

Knowledge and memory

Does conversation history automatically become long-term knowledge?

No. Content entering a knowledge space must be traceable, reviewable and backed by an explicit authoritative source. A complete conversation is source material, not knowledge.

Can a knowledge update change a task already in flight?

No. A task freezes its knowledge snapshot at creation, and an in-flight task does not drift with personal configuration or knowledge updates. Knowledge recall during execution does read the latest effective content live and re-checks authorisation — so revoking a permission takes effect immediately.

What happens to tasks if the retrieval service goes down?

A snapshot that has already been frozen does not depend on an online index and can be replayed deterministically. Task preflight fails closed when the retrieval service is configured but unavailable; a conversation degrades to relational database retrieval and marks the reason.

Does a knowledge base update require a re-publish?

A knowledge base does not produce a whole-corpus release. Each document has its own draft and published version, and each read selects, live, the effective version the reader is authorised for at that moment.

Maturity and procurement

Can it be used in production today?

That needs a distinction. The repository already contains a working vertical slice covering the full path from the domain model to the console experience. But a highly available control plane, enterprise single sign-on and audit, production installation and upgrade, and full end-to-end acceptance against real external systems are still under construction.

A procurement evaluation should confirm each item against the four verification levels, and should not accept "it deploys" or "it ran one task successfully" in place of business acceptance.

How do I confirm a capability really works?

Ask for level-four evidence for that capability: a real signed-in principal completing the corresponding read and write path against a real model gateway, Git service, connector or data plane.

The first three levels — implemented, passing gates, deployed — cannot substitute for it.

What if there is no level-four evidence?

Describe the target shape, and mark explicitly that it is not yet verified. This manual's usage rule governs the product itself, not only the documentation.

Can I contribute?

Source, deployment instructions and architecture documentation are in the project repository. Licence and contribution terms are governed by the actual statement in that repository.