Agent-Accessible Enterprise Docs
Modern integration work increasingly happens with coding agents beside the engineer. If the most useful enterprise setup guidance sits behind an interactive login wall, those agents cannot reliably help with implementation, review, or troubleshooting.
AxonFlow's documentation boundary is designed around that reality:
- generic enterprise architecture and setup guidance should be public
- customer-specific onboarding packs should stay private
- secrets, environment details, commercial terms, and private support context should never be pasted into public docs or agent prompts
Why This Matters
Teams evaluating AxonFlow often want to ask a coding agent questions such as:
- which runtime path should this service call?
- how should SSO and SCIM fit our rollout?
- what does the deployment mode imply for audit, telemetry, and data boundaries?
- which compliance control does a policy or approval workflow support?
- what should we validate before moving from evaluation to production?
Those questions are safe to answer from public documentation. They do not require customer names, private architecture diagrams, live credentials, or contract details.
Public by Default for Generic Enterprise Guidance
The following enterprise topics should be public and agent-readable:
| Area | Public docs to use |
|---|---|
| Runtime architecture | Runtime Request Paths, Runtime Surface Map |
| Deployment planning | Deployment Mode Matrix, Evaluation Rollout Guide |
| Enterprise readiness | Enterprise Overview, Procurement Readiness |
| Identity | Identity Overview, SSO, SAML, SCIM |
| Governance | Policy Hierarchy, Human in the Loop, Audit Logging |
| Trust | Trust Center, Security Control Matrix |
| Compliance | Compliance Overview and the regulated-industry framework guides |
This gives engineers and agents enough context to plan integrations without asking for protected-docs access.
Private by Default for Customer-Specific Material
Keep these in protected partner packs, private support channels, or customer-specific repositories:
- named customer onboarding packs
- environment-specific runbooks, hostnames, tenant IDs, or network details
- screenshots that expose customer configuration
- commercial terms, discounts, invoices, procurement messages, or legal negotiation notes
- private support threads, incident context, or security findings
- evidence packs that are contractually or operationally restricted
- credentials, tokens, secrets, and private keys
The rule is simple: if the page only makes sense for one customer or one private deployment, it should not be public.
Recommended Workflow With Coding Agents
When using Claude Code, Codex, or another coding agent:
- point the agent at the public AxonFlow docs first
- keep customer-specific partner packs out of the prompt unless the customer has approved that workflow
- redact hostnames, tenant IDs, tokens, and personal data before sharing snippets
- ask the agent to cite which public docs it used when producing implementation guidance
- treat the agent's output as a draft that an engineer reviews before applying it to production
This approach keeps agents useful without turning private customer context into accidental training or prompt material.
What Still Requires Human Review
Public documentation can help agents plan and implement, but humans should still review:
- production deployment topology
- policy hierarchy changes
- group-to-role mappings
- compliance interpretations
- procurement or contractual claims
- any answer that depends on a customer's private architecture
For regulated teams, the safest pattern is public docs for implementation mechanics plus private review for environment-specific decisions.
