Observed
Read-only discovery, diagnostics and recommendations. Latifold does not automatically correct these resources.
From your coding agent to your existing cloud.
You ask for an application feature. Your coding agent writes the code, identifies the infrastructure it needs, and works with Latifold to prepare it in your existing cloud. Your policies govern what proceeds automatically and what needs approval.
Connect first.
Expand authority deliberately.
The app is preparing to go online. AWS, Azure and Google Cloud are supported; available resources and operations vary by provider. These examples describe the product design.
- 01
Connect what already runs
Begin with read-only access to supported resources in an existing AWS, Azure or Google Cloud account. No rebuild or workload migration is required.
- 02
Keep your coding workflow
Your coding agent writes the feature, identifies the infrastructure its code requires, and sends that requirement to Latifold through MCP or the versioned REST API.
- 03
Set authority deliberately
Humans set accounts, budgets, permitted resource types and approvals. Add narrowly scoped write access only for supported operations.
Your agent changes the code.
Your infrastructure follows.
An upload handler needs storage. A background job needs a queue and worker. Follow how the agent discovers each requirement and Latifold plans, applies and verifies the matching infrastructure.
One resource.
One authoritative source of truth.
Latifold applies changes through cloud APIs or the resource’s existing infrastructure-as-code workflow. Terraform, OpenTofu, CloudFormation and CDK workflows remain authoritative for the resources they manage.
Externally managed
Terraform, OpenTofu, CloudFormation, CDK or another owner stays authoritative. Proposed changes go through its existing review and deployment workflow.
Latifold-managed
Latifold's versioned desired state is authoritative. Authorised changes use native cloud APIs and controlled reconciliation within the agreed scope.
Resources authorised for Latifold management use native cloud APIs. IaC-managed resources change through their existing workflow. Restarts and other one-off runtime actions are recorded as operations, rather than permanent configuration changes.
Your agents propose.
Your rules decide.
Humans set accounts, permissions, budgets and approval rules. Latifold is designed to evaluate changes with deterministic policies before execution. An agent can propose a correction; it cannot override a denied policy.
- Approval belongs to a plan
- Tie approval to the exact plan, configuration and policy revision. Revalidate when the plan or relevant environment changes.
- Cost estimates have limits
- An estimated cost increase can trigger approval. Actual spending limits need separate runtime enforcement; an estimate is not a hard budget guarantee.
- Record the actual outcome
- Keep agent identity, human authorisation, provider results and verification together. Surface concurrent changes, partial failures and unresolved drift.
The next task starts with a record.
The proposed Latifold resource model is declarative, provider-independent and stored and versioned centrally. Start without IaC, or work with the infrastructure code you already use. JSON/YAML viewing and export are planned for portability.
The agent
Interprets your intent, writes code, requests infrastructure context and explains evidence and uncertainty.
Latifold
Determines ownership, evaluates policy, orchestrates authorised work and tracks what actually happened.
The human
Sets the rules and reviews sensitive changes. The dashboard supports account setup, approvals, policies and audit review.
Keep coding. Bring your cloud into the workflow.
Give your coding agent context on existing infrastructure and the ability to make changes within your permissions and policies. Changes proceed automatically unless your rules require approval.