Straight answers about professional control, early access, and the information the current public site can verify.
Supported write operations are designed around a propose → confirm → execute workflow. Read-Only Mode is intended for workflows where write tools should not run.
No. It produces findings to support professional review. It does not certify compliance, guarantee correctness, or replace engineering judgment.
A product mode intended to keep Esattia focused on inspection, queries, navigation, and findings while blocking write tools according to the current implementation.
Yes for supported model-changing workflows presented on this site: Esattia separates the proposed action from confirmation and execution.
The public site does not lock in a definitive provider/model list here. Available providers and model options should be confirmed for each early-access release.
Esattia includes a bring-your-own-AI direction over MCP. Exact supported account/provider behavior should be confirmed for the current release during onboarding.
This requires release-specific confirmation. The website intentionally avoids making a blanket data-residency or “nothing leaves your machine” claim until the deployed architecture and providers are documented.
Not from the public website today. The current flow is Request access.
The supported version range should be confirmed during early access and published once the current release matrix is finalized.
The public site does not publish a numeric count until the current product inventory is verified from the application source.
For release-specific technical, data, or access questions, contact Esattia directly.