Allow about one minute. Start with a familiar task: deploying an application with a database, private networking, backups, and checks that prove the application works. An agent can help create the automation. The useful deliverable is the entire executable workflow, including how the tools work together. Colors supplies an SDK for writing that workflow. Once reviewed and tested, the code can run from a terminal or CI without a model at execution time. This talk follows the path from infrastructure requirements to that reusable program. Explain that convergence means bringing observed infrastructure toward the configuration's desired state. It remains a property the workflow must implement and verify.
Allow about one minute. Generating infrastructure definitions and playbooks is useful, but someone must still decide when each tool runs and what the next step receives. That coordination often remains in shell history, manual instructions, or an agent session. It deserves the same review and version control as the files themselves. Colors moves the request up one level: describe the infrastructure and ask the agent to write both the tool-specific code and its orchestration. OpenTofu and Ansible are the current package examples. Their responsibilities vary with the package, and Colors does not replace their underlying resource or configuration logic.
Allow about ninety seconds. A useful request names the infrastructure shape, provider, network restrictions, backup expectations, and what success means. The agent uses those requirements to write colors.yml and the workflow that interprets it. The configuration schema belongs to the package; colors.yml is not a universal catalog of every possible resource. Acceptance checks belong in the resulting automation. For example, a process being alive is weaker evidence than writing an observation through the application API and reading it back. Review the sequence, inputs, retries, partial-failure behavior, and verification. Generated code still needs testing. Ask the agent to revise the program when the requirements or evidence change, so the improvement remains available for subsequent runs.
Allow about one minute. The current Package Skills focus on OpenTofu and Ansible, but those tools do not define the boundary of Colors. A workflow can invoke any DevOps CLI. Kubernetes tools illustrate another possible application of the workflow model; this slide does not claim that a particular Kubernetes Package Skill already ships. The author chooses appropriate tools and implements their ordering and checks. Red, Green, and Blue are the SDK implementations for three programming environments. They offer a choice of language for the same workflow approach. In the Langfuse example, the three implementations share the same configuration and lifecycle verbs, and its parity checks compare rendered outputs.
Allow about one minute. The word Skill can suggest instructions that only make sense inside an agent. A Package Skill includes an executable program. Its instructions help users and agents understand and use that program. The workflow reads desired state from colors.yml, coordinates CLI tools, and checks outcomes. The code survives the session that produced it and can enter the team's normal code review and release process. Reuse is valuable even when every run is triggered by a human or existing CI system. Reproducibility also depends on controlled dependencies, inputs, and external systems. A package does not gain that property merely because its code is committed.
Allow about ninety seconds. A Context Skill is distilled knowledge from a verified build. It records operational facts that are expensive to rediscover, including failures, fixes, and the versions for which they were observed. It can direct the agent to maintained companion code rather than duplicating that code in prose. The Langfuse build, for example, exposed cases where a healthy service or a successful response did not prove the intended application behavior. A Context Skill helps the agent avoid repeating such mistakes. It is evidence with a scope, not a guarantee of a perfect solution. New versions, providers, and requirements need their own verification. The two skill types work together: the Package Skill carries the executable workflow; the Context Skill explains relevant lessons behind a working implementation.
Allow about ninety seconds. This is an excerpt from the actual six-machine Vultr configuration described on the Colors website, not a complete runnable configuration. The application host runs Langfuse web, worker, and Caddy. A separate host runs self-hosted Neon for Postgres; Redis has its own host; the three ClickHouse hosts carry their Keeper quorum. R2 is an external object store and is not counted among the six machines. The package provisions resources and coordinates configuration across the tiers. Its checks include application ingestion and read-back, permitted network connections, and required refusals. Recovery is a separate rehearsal command that restores both stores and boots the application against restored data. The historical build report records eleven converges and lessons that informed the checks. This is why the workflow needs evidence beyond an exit code from the provisioning tool.
Allow about ninety seconds. These commands use the Langfuse package's documented launcher interface. Installation copies the Red payload into the working directory and makes it executable. The package needs a complete colors.yml and its documented dependencies; the preceding excerpt is not enough. The build command renders locally without provider calls or credentials. The dry run walks the workflow while skipping side effects; it is not proof that a live deployment will succeed. The create command performs the actual convergence and runs the package's checks, so only run it in an authorized environment with the required credentials. No model participates in these launcher commands. A CI runner can execute the same reviewed code. If the installed skill is updated, copy the launcher again, because the local launcher is a copy of the payload.
Allow about ninety seconds. This is a deployment pattern a team can implement, not an automatic security boundary supplied by Colors. The development environment can omit production credentials while the agent writes code and performs local rendering and tests. Review and pin the resulting version before an operator or CI runner executes it. That runner needs the permissions required by the actual operations. Keeping credentials local says little about which processes can access them. Separation depends on the environment and its controls. If an agent runs inside the credentialed environment, it may have access under that environment's permissions. The key product distinction is that Colors does not require that arrangement. Existing change approval and credential management processes can remain responsible for authorizing production execution.
Allow about one minute. Invite the audience to the Community Town Hall on Friday, 18 September 2026, at 17:00 CEST, which is 15:00 UTC. It is online, free, and scheduled for one hour. The registration link and QR code both open https://luma.com/ci9bek4c. Describe the session as a live provisioning demo, roadmap discussion, and Q&A. Encourage attendees to bring a concrete infrastructure requirement or a question about how the workflow would fit their deployment process. Leave this slide visible while taking questions. Supporting resources for follow-up are https://www.getcolors.ai/skills and https://www.getcolors.ai/#workflow. Registration for the Community Town Hall is the primary action for this introduction.