# XYZ by FORMATION Full Digest

Source site: https://formationxyz.com/
Primary language: English
Alternate language: Deutsch (https://formationxyz.com/de/)

## Company
Name: XYZ by FORMATION
Description: XYZ by FORMATION is a Berlin-based AI consultancy and venture lab focused on AI consulting and implementation, workflow automation, and practical AI systems for small teams.
Location: Berlin, Germany
Email: info@tryformation.com
Website: https://formationxyz.com/
LinkedIn: https://www.linkedin.com/company/formationteams/
GitHub: https://github.com/formation-res
X: https://x.com/formationapp
Founders: Ian Hannigan, Dr. Jilles Van Gurp

## Home page summary
Title: XYZ by FORMATION
URL: https://formationxyz.com/
Summary: Move faster with your team, get more done. Tell us what you want automated. We’ll design, deploy, and hand over an agent that’s ready to work from day one. We design and build practical AI systems, workflow automation, and AI integrations that remove repetitive work and operational bottlenecks, so small teams can scale without adding drag.
Services summary: Practical AI systems, workflow automation, and agentic workflows that remove busywork and help small teams move faster. 
Spatial AI summary: Spatial AI, search, and mapping systems for teams that need clearer answers from location data.

## Services
Title: OpenClaw Workflow (Discontinued)
URL: https://formationxyz.com/services/openclaw-white-glove-setup/
Description: Discontinued. XYZ no longer recommends OpenClaw for client work because it is unstable, slow, hard to secure, and too fragile for business users.
Price: Discontinued
Billing type: one-time
Delivery window: No longer offered
Team size: 2-3 people
Who to involve: Founder or team lead, implementation owner, technical contact
Prerequisites: Not offered. Consider Claude Cowork, Codex, Perplexity Computer, or a scoped custom workflow instead.
Body: Discontinued This service is discontinued. XYZ no longer recommends OpenClaw for client work. We tested it in real agentic workflows and found useful ideas, but the product is too unstable, slow, hard to secure, and operationally fragile for business users. Read the rationale in We’re using OpenClaw, it sucks! . Problem Teams still need AI workflow automation across tools and handoffs, but OpenClaw is no longer the route we recommend. The product makes useful ideas visible, then creates too much operational drag around reliability, speed, security, and maintenance. Right Fit This page remains online for context and for anyone following older OpenClaw links. If you need one practical workflow, start with Claude Cowork Workflow , Codex Workflow , or Perplexity Computer Workflow , depending on where the work happens. What You Get We no longer sell OpenClaw setup work. For current projects, XYZ scopes the workflow first and then chooses a more stable route. That may mean a supervised desktop workflow, a repo-based Codex workflow, a browser/research workflow, or a custom automation pattern that avoids OpenClaw’s reliability and security issues. How XYZ Runs It For work that would previously have pointed to OpenClaw, we now start with the workflow and risk model rather than the tool. The first step is to identify the real handoffs, the systems involved, and the review points that make the workflow safe enough to run. Choose This Instead Of Do not choose OpenClaw for new client work. If your work is document-heavy, use Claude Cowork Workflow . If it is technical or repo-based, use Codex Workflow . If it is browser or research-heavy, use Perplexity Computer Workflow . If you need a larger governed setup around a business function, start with Small Autonomous Organization .


Title: Claude Cowork Workflow
URL: https://formationxyz.com/services/claude-cowork-setup/
Description: Set up one Claude Cowork workflow for non-technical business work such as research, documents, and repeatable team tasks, with clear rules and review points.
Price: EUR3K
Billing type: one-time
Delivery window: 2 days
Team size: 2-3 people
Who to involve: Workflow owner, team lead, technical contact
Prerequisites: Target knowledge-work flows, representative files, access boundaries, and a clear owner for rollout
Body: Problem Teams buy capable AI tools and still end up using them in inconsistent ways. Research, document work, and synthesis often stay manual because nobody has turned the tool into one simple workflow the team can use every day. The missed opportunity is usually practical business process automation, not model quality. Right Fit This service is built around Claude Cowork . Choose it when the work is mostly about files, documents, research, and desktop tasks rather than code in repositories. It is one of the best fits here for non-technical business users, along with Perplexity Computer, especially for knowledge work automation and document workflow automation. What You Get You get a Claude Cowork workflow built around one recurring task the team already knows well. That means less repetitive manual work and a faster path through research, documents, or synthesis each time the task comes up. It also gives you a practical stepping stone toward automating more workflows later, either by yourselves or with our help. That usually includes working instructions, access boundaries, workflow steps, review points, and a clear pattern your team can follow. How XYZ Runs It We begin with a free call to pick the workflow that will create the most value for the team first. After that, XYZ sets up the environment, connects the right tools, defines the guard rails, and shows the team how to use the workflow safely day to day. The goal is to make it part of normal work, not something people only try once, so the team gets lasting value from AI-assisted knowledge work. Choose This Instead Of Choose this instead of Codex Workflow when the work is more document- and research-centric than code-centric. If the workflow needs to run across several tools, channels, and handoffs, start with Your Agentic Use Case so XYZ can scope a safer route. OpenClaw Workflow is discontinued and no longer recommended.


Title: Codex Workflow
URL: https://formationxyz.com/services/codex-setup/
Description: Set up one Codex workflow for repo work, technical tasks, and research, with clear approvals and review. It plays a similar role to Claude Cowork, but for code-oriented work.
Price: EUR3K
Billing type: one-time
Delivery window: 2 days
Team size: 2-3 people
Who to involve: Workflow owner, technical contact, team lead
Prerequisites: Target workflows, repo or file context, access rules, and a clear owner for approvals and review
Body: Problem Technical teams often see the value of agentic tools but get stuck between random experimentation and barely using them at all. Without one clear workflow, approval rules, and repeatable task patterns, the tool never becomes part of normal delivery. The gap is usually in technical workflow automation, not in access to the model. Right Fit This service is built around Codex . If you already have a ChatGPT Plus subscription, Codex is already included with that subscription and covers a similar kind of workflow to Claude Cowork. Choose it when the work lives close to repositories, files, scripts, and technical operations, and when the team is comfortable in a more code-oriented environment. It is a strong fit for engineering workflow automation, DevOps automation, and repo-based AI workflows. What You Get You get a Codex workflow the team can use in real delivery work. The payoff is less manual technical effort, fewer repetitive tasks for senior people, and a clearer path to automating similar workflows later, either by yourselves or with our help. That includes working instructions, approval boundaries, sandboxing habits, workflow steps, and clear rules for what the agent can do alone and what still needs review. How XYZ Runs It The first step is a free call to identify the workflow that matters most and is realistic to automate first. Then XYZ helps set up the environment, documents the rules, and coaches the team on safe daily use. We focus on practical tasks such as repo support, triage, drafting, and technical execution so the workflow is useful right away and can become a repeatable part of software delivery. Choose This Instead Of Choose this instead of Claude Cowork Workflow when the work is more code- and repo-centric. If you already have ChatGPT Plus, Codex may also be the easiest tool to start with. If the workflow needs to span several tools, channels, or manual handoffs beyond the engineering environment, start with Your Agentic Use Case . OpenClaw Workflow is discontinued and no longer recommended.


Title: Agentic Website
URL: https://formationxyz.com/services/existing-website-agentic-migration/
Description: Turn an existing website into a structured, agent-ready system for faster SEO operations, content updates, and reliable website workflow automation.
Price: EUR5K
Billing type: one-time
Delivery window: 5 days
Team size: 2-4 people
Who to involve: Founder, website owner, technical contact
Prerequisites: Existing website access, content source, hosting and domain access
Body: Problem Many sites work well enough to stay online but are difficult to operate. Content is scattered across the CMS, templates, and ad hoc fields. Reusable sections are copied instead of shared. Metadata and internal linking are inconsistent. Small changes take too long because nobody is sure where the real source of truth lives or what else a change might break. Right Fit Choose this when the main problem is website structure and maintainability. It is a fit for teams with an existing site that works well enough today but is too fragile, messy, or slow to support faster content operations. What You Get You get a cleaner website foundation that is easier to edit, extend, and trust. We reorganize content, UI copy, shared data, templates, and reusable sections so the structure matches how the site is actually operated. Typical outputs include clearer page models, content moved into the right source files or fields, shared elements pulled out of duplicated pages, and checks that catch mistakes before they go live. How XYZ Runs It XYZ starts by mapping how the current site works: where content lives, how templates are structured, where duplication has crept in, and which parts of the publishing flow create risk or slow the team down. We then redesign the structure around real operating needs and move the existing site into that structure without losing what already works. That can include splitting mixed content into proper source-of-truth locations, consolidating repeated sections into shared components or data, cleaning up page models, tightening metadata handling, and adding practical checks around editing and publishing. The result is a site that supports faster content work and gives agent tools a structure they can work with safely. Choose This Instead Of Choose this before Agentic Content Management if the site structure is the real bottleneck. If the structure is already sound and you mainly need ongoing operating support, Webmaster is the better fit.


Title: Perplexity Computer Workflow
URL: https://formationxyz.com/services/perplexity-computer-workflow/
Description: Set up one Perplexity Computer workflow for non-technical business work, with clear scope, practical steps, and review points.
Price: EUR3K
Billing type: one-time
Delivery window: 2 days
Team size: 2-3 people
Who to involve: Workflow owner, team lead, technical contact
Prerequisites: Target research or browser workflow, the sites and tools involved, access boundaries, and a clear owner for review
Body: Problem Teams often want to automate real day-to-day work, but they stay stuck in one-off prompting. The tool may look impressive in a demo, but the real value comes from shaping one repeatable workflow around a task the team actually cares about. That is where practical AI workflow automation starts to matter. Right Fit This service is built around Perplexity Computer . Choose it when you want a general-purpose agent to handle non-technical business work across research, tools, websites, and longer-running tasks. It is one of the best fits here for non-technical business users, along with Claude Cowork, especially for AI task automation and business workflow automation. What You Get You get a Perplexity Computer workflow centered on one real task the team wants off its plate. That cuts repeated manual steps, saves time, and gives you a practical stepping stone toward automating more workflows later, either by yourselves or with our help. That usually includes the task steps, tool access, review points, handoffs, and clear rules for what the agent can do on its own and what still needs a person. How XYZ Runs It We use the free call to narrow in on the workflow that matters most and is worth tackling first. Then XYZ maps the target task, sets up the workflow, defines the boundaries, and helps your team use it safely in day-to-day work so the automation is practical, reviewable, and worth repeating. Choose This Instead Of Choose this instead of Claude Cowork Workflow when Perplexity Computer is the tool your team wants to standardize on for non-technical workflow work. Choose this when you want one practical workflow first rather than a broader multi-tool operating layer. OpenClaw Workflow is discontinued and no longer recommended.


Title: Agentic Content Management
URL: https://formationxyz.com/services/agentic-promptable-website/
Description: Set up a promptable website workflow so pages, copy, FAQs, and SEO updates ship faster without losing review control.
Price: EUR5K
Billing type: one-time
Delivery window: 1 week
Team size: 2-4 people
Who to involve: Founder, website owner, content owner
Prerequisites: Core pages, desired user journeys, access to the live site or repo
Body: Problem Many teams can update their site, but every routine change still turns into a mini project. New pages, copy refreshes, CTA changes, FAQ updates, and SEO fixes pile up because the workflow is too manual for the amount of change the business needs. Right Fit Choose this when the website structure is already workable and the main need is faster content operations. It fits teams that want natural-language input to produce reviewable website changes without turning the site into a mess. What You Get You get a promptable editing workflow for the kinds of website work that happen every week. That can include landing pages, hero and CTA rewrites, service-page updates, FAQ expansion, metadata refreshes, campaign copy, and publish-ready drafts that follow a consistent structure for your site. How XYZ Runs It XYZ sets up the editing workflow around your existing website structure, content model, and publishing process. We define the guard rails, the allowed change patterns, and the reusable skills for the website jobs your team does most often. That can include updating existing pages, drafting new pages from a pattern, expanding FAQs, refreshing metadata, or applying site-wide copy changes. The team works through these jobs in plain language with an agentic coding tool. The workflow turns those requests into concrete edits, runs the checks your site needs, and stages the result in a reviewable form. That gives the team a faster editing path without losing structure or publishing discipline. Choose This Instead Of Choose this after Agentic Website if the structure already supports safe edits. If you want XYZ to keep running website operations over time, Webmaster is the better ongoing service.


Title: NemoClaw Setup
URL: https://formationxyz.com/services/nemoclaw-setup/
Description: Set up NemoClaw as a controlled OpenClaw and OpenShell stack with stronger privacy and security guardrails from day one.
Price: EUR6K
Billing type: one-time
Delivery window: 4 days
Team size: 3-5 people
Who to involve: Technical lead, security or compliance owner, workflow owner
Prerequisites: Target workflows, infrastructure constraints, security requirements, model preferences, and the internal systems the agents need to reach
Body: Problem Some teams want the upside of agentic work without relying on a lighter desktop setup or a closed vendor stack. The issue is usually not interest. It is finding a setup that gets them into agentic work quickly while adding stronger privacy and security guardrails from the start. Right Fit Choose this when you want a faster path into a controlled OpenClaw-based setup with stronger attention to privacy, security, and permissions. It fits smaller teams evaluating NemoClaw because it packages OpenClaw and OpenShell together and offers a cleaner starting point than assembling the stack manually. It can become part of a broader enterprise model later, but that is not the starting scope here. What You Get You get a working NemoClaw setup shaped around your operating constraints. That usually includes the base install, environment setup, permission boundaries, starter workflow patterns, and the first controlled agent tasks mapped to real internal work. Where relevant, we also help you evaluate whether the NVIDIA-hosted VM preview path is the right starting point or whether a different deployment model makes more sense. How XYZ Runs It XYZ scopes the target workflows, sets up the initial NemoClaw environment, configures the privacy and security guardrails, and works through the first production-relevant agent routines with your team. We focus on making the setup usable inside a real operating environment, not just technically possible. Choose This Instead Of Choose this instead of OpenClaw Setup when the main requirement is a faster packaged install path with added privacy and security guardrails around the OpenClaw stack. If the real goal is team-wide engineering adoption rather than platform setup, Engineering Team Agentic Setup is usually the better next step. Next Steps The next step is a short scoping call to confirm whether NemoClaw is the right starting point, which workflows you want to run first, and whether the NVIDIA-hosted VM preview path or a different deployment model fits better. From there XYZ turns that into a 4-day setup plan with clear guardrails, owners, and first-use cases.


Title: Webmaster
URL: https://formationxyz.com/services/agentic-website-webmaster/
Description: Keep your website updated with recurring SEO operations, publishing support, technical fixes, and structured website workflow automation.
Price: EUR4K
Billing type: recurring
Delivery window: 3-5 days to launch
Team size: 2-3 people
Who to involve: Founder, website owner, point person for approvals
Prerequisites: Existing website, update cadence, priorities and approval workflow
Body: Problem Many websites drift out of date because routine changes are too hard to make. A small copy fix needs technical help. SEO tasks sit on a backlog. Landing pages take too long to publish. Marketing avoids the CMS because it is brittle, slow, or easy to get wrong. Over time the site stops reflecting the business because nobody can keep the weekly work moving. Right Fit Choose this when you need ongoing website operations support rather than a one-time setup project. It fits teams that already have a site and want a reliable operator to keep content, maintenance, and small improvements moving. What You Get We set up an agentic webmaster around your existing site so routine website work can move again. That can include content updates, SEO fixes, metadata cleanup, internal linking improvements, FAQ updates, landing pages, product pages, and small technical maintenance tasks. You use it through the AI tools you already prefer, such as Claude Code, Codex, or similar agentic coding tools. You describe the change in plain language. The webmaster turns that into a real website update, follows the workflow we define for your site, runs checks, and stages the result for review. A rough request can become a reviewable update. A site-wide wording change, a batch of metadata fixes, or a new service page no longer has to start as a manual mini project. How XYZ Runs It XYZ connects agent tools to your actual website stack and workflow. We define the skills, guard rails, and access needed for your site structure, repositories, CMS, approval steps, and publishing process. The agent needs to know where content lives, how page types differ, how updates should be validated, what it is allowed to change, and what should always stay reviewable by a person. With your input, we adapt these skills to the recurring jobs that matter on your site. That might mean content refreshes, SEO maintenance, CTA updates, FAQ improvements, publishing new pages, or technical housekeeping. We then run through real updates with your team so the workflow is grounded in actual website work instead of generic prompting. By the time we are done, you have a website workflow that your team can use day to day. Changes start from intent, move through a defined implementation path, and reach approval in a form that is easier to trust. Choose This Instead Of Choose this when the site already exists and needs ongoing care. If the structure is the main problem, start with Agentic Website . If you want your team to run promptable editing directly, Agentic Content Management is the better fit.


Title: Board Pack Copilot
URL: https://formationxyz.com/services/board-pack-copilot/
Description: Build a repeatable board-pack workflow that turns scattered KPIs, updates, and narrative into a reviewable monthly decision pack.
Price: EUR4K
Billing type: one-time
Delivery window: 4 days
Team size: 2-3 people
Who to involve: Founder or CEO, finance or ops lead, person who assembles board materials today
Prerequisites: Current board materials, KPI sources, recurring reporting inputs, and a clear review owner
Body: Problem Board updates often require too much last-minute manual work. Metrics live in different tools, narrative gets rebuilt from scratch, and the team spends too much time assembling context instead of sharpening the decisions that matter. Right Fit Choose this when leadership already has recurring board or investor-facing reporting but wants a faster, more controlled way to prepare it. It is a good first agentic workflow because the cadence is clear, the source material is known, and review stays with the team. What You Get You get a repeatable board-pack workflow that gathers source inputs, drafts KPI commentary, prepares the narrative structure, and packages the material for review. The result is a faster path from raw reporting inputs to a decision-ready pack. How XYZ Runs It XYZ maps the current board-pack process, defines the source inputs and approval boundaries, and sets up the first workflow around your real monthly or quarterly reporting cycle. We focus on making the prep faster while keeping the final judgment and sign-off with leadership. Choose This Instead Of Choose this when the reporting rhythm is already clear and the main problem is assembly and synthesis. If you want a broader recurring leadership summary beyond board reporting, Exec Briefing Agent is the better fit. If you need the workflow to keep running every month, Investor Update Engine is the natural next step.


Title: SEO Manager
URL: https://formationxyz.com/services/agentic-seo-scanner-optimizer/
Description: Run SEO as a recurring operating workflow so technical SEO improvements, content updates, and Generative Engine Optimization opportunities do not sit idle.
Price: EUR6K
Billing type: recurring
Delivery window: 1 week to first pass
Team size: 2-3 people
Who to involve: Marketing owner, website owner, technical contact
Prerequisites: Site access, analytics/search context, priority pages and target terms
Body: Problem SEO work often sits in a vague middle ground where everyone agrees it matters but no one keeps the cycle moving. Technical SEO issues, content gaps, metadata fixes, internal linking improvements, and newer Generative Engine Optimization opportunities stay in the backlog for too long. Right Fit Choose this when you want search performance improved through a recurring operating rhythm rather than occasional SEO projects. It fits teams that already have a site and need priorities surfaced, sequenced, and acted on consistently. What You Get You get a standing SEO workflow that keeps identifying and acting on the highest-value opportunities. That can include scans, fixes, page refreshes, content-gap summaries, prioritization, Generative Engine Optimization experiments, and reporting on what changed and what should happen next. How XYZ Runs It XYZ reviews the site, identifies the highest-leverage work first, and helps establish recurring cycles for scanning, prioritization, implementation, and reporting. The goal is a compounding workflow for SEO operations, not sporadic bursts of SEO activity. Choose This Instead Of Choose this when search visibility is the operating problem. If the bigger issue is general site maintenance and publishing support, Webmaster is broader. If the site needs structural cleanup first, start with Agentic Website .


Title: Due Diligence Room Assistant
URL: https://formationxyz.com/services/due-diligence-room-assistant/
Description: Set up a controlled diligence workflow for gathering documents, spotting gaps, and preparing faster responses during fundraising or partner review.
Price: EUR6K
Billing type: one-time
Delivery window: 1 week
Team size: 2-4 people
Who to involve: Founder, finance lead, legal or ops contact, owner of the diligence room
Prerequisites: Current diligence materials, access rules, expected question areas, and a clear owner for approvals
Body: Problem Diligence processes create repetitive, stressful document work at exactly the moment the team has the least spare capacity. Files are scattered, requests keep shifting, and too much effort goes into finding, reformatting, and re-answering material that should be easier to manage. Right Fit Choose this when you are preparing for fundraising, partner diligence, M&A review, or another structured information request process. It fits teams that want a safer and faster way to gather materials and respond without losing control of sensitive information. What You Get You get a diligence workflow that helps collect source documents, identify missing items, structure common answer areas, and prepare reviewable response drafts. The goal is not autonomous disclosure. It is cleaner preparation and faster handling under human control. How XYZ Runs It XYZ maps the request flow, organizes the materials, defines the access boundaries, and sets up the first workflow around the real diligence process you expect to run. We focus on reducing search and coordination overhead while keeping approvals explicit. Choose This Instead Of Choose this when the process is diligence-heavy and document-driven. If the recurring need is meeting prep and decision synthesis, Meeting Prep and Decision Pack is a better fit. If the workflow is highly specific and unusual, Your Agentic Use Case may be the better path.


Title: Market Intelligence
URL: https://formationxyz.com/services/agentic-competitive-landscape-scanner/
Description: Track competitor moves, market signals, and category shifts in a structured way so strategy and sales use fresher evidence.
Price: EUR8K
Billing type: recurring
Delivery window: 1 week to first brief
Team size: 2-3 people
Who to involve: Founder, strategy owner, market lead
Prerequisites: Competitor set, market focus, reporting priorities
Body: Problem Competitor and market changes usually reach teams too late. Important moves get noticed through anecdotes, scattered screenshots, or chance conversations instead of through a usable operating rhythm. Right Fit Choose this when you want a standing intelligence layer for strategy, product, positioning, or sales. It fits teams that already know the market matters but do not have a disciplined way to monitor it. What You Get You get a curated stream of market signals, not a pile of alerts. That can include competitor tracking, pricing changes, launch monitoring, messaging shifts, category summaries, and regular briefs that explain what changed, why it matters, and what to do next. How XYZ Runs It XYZ defines the watchlist, sets the monitoring logic, and turns the output into summaries your team can actually use. We shape the cadence, thresholds, and escalation rules so the signal stays useful instead of noisy. Choose This Instead Of Choose this when the problem is market visibility. If the bottleneck is internal prioritization, start with Roadmap Agentic Review . If you already know the exact workflow you want to automate, Your Agentic Use Case is the more direct option.


Title: Agentic Slides
URL: https://formationxyz.com/services/agentic-slide-generation/
Description: Build presentations through a structured Reveal.js workflow so decks are faster to produce, easier to reuse, and better suited to AI-assisted work.
Price: EUR5K
Billing type: one-time
Delivery window: 1 week
Team size: 2-3 people
Who to involve: Presentation owner, subject matter expert, brand or design contact
Prerequisites: Narrative, source material, target audience, and visual references or brand constraints
Body: Problem Presentation work is usually trapped in manual slide editing, one-off deck files, and last-minute formatting loops. That makes decks slow to produce, hard to reuse, and awkward to improve with AI. Right Fit Choose this when presentations are important enough to deserve a better production workflow. It fits teams that produce recurring decks for sales, events, investor updates, workshops, or customer education and want more speed without losing control of narrative or design. What You Get You get a Reveal.js-based presentation workflow with structure, styling, and generation patterns that can be reused. That includes a practical repo setup, a repeatable way to turn source material into decks, and a clearer process for review and export. How XYZ Runs It XYZ helps shift the workflow away from manual slide assembly, sets up the repo structure and guard rails, and shows the team how to generate and refine decks through code-centric AI workflows. The outcome is a system for deck production, not just one deck. Choose This Instead Of Choose this when repeated presentation production is the problem. If the wider issue is how your engineering team adopts agentic workflows, Engineering Team Agentic Setup is the better fit.


Title: Engineering Team Agentic Setup
URL: https://formationxyz.com/services/agentic-engineering-team-setup/
Description: Help your engineering team adopt agentic tooling, AI workflows, and reviewable automation that raise delivery speed without losing control.
Price: EUR8K
Billing type: one-time
Delivery window: 1-2 weeks
Team size: 3-5 people
Who to involve: Engineering lead, founder or sponsor, technical operators
Prerequisites: Current stack, delivery goals, team structure and access requirements
Body: Problem Engineering teams can see the upside of agentic coding and automation, but rollout often stalls between hype and risk. Without clear rules, repeatable AI workflows, and a sane review model, the team does not get the speed gains without worrying about quality or security. Right Fit Choose this when you want agentic work to improve delivery inside a real engineering environment. It is a fit for teams that need practical patterns for coding, release support, DevOps chores, test loops, triage, and other technical workflows. What You Get You get a working starter model for agentic engineering. That usually includes instruction files, workflow patterns, review habits, permission boundaries, human approval points, and a few production-relevant use cases the team has already exercised. How XYZ Runs It XYZ works with engineering leads and operators to configure the toolchain, shape the operating rules, and pilot the first repeatable AI workflows in the repo and surrounding systems. The goal is to leave the team with a setup they can keep using, not a one-off demo. Choose This Instead Of Choose this instead of Codex Setup when the scope is team-wide engineering adoption rather than an individual or small workbench setup. If the broader company needs workflow redesign beyond engineering, Company-Wide Agentic Workflow is the better next step.


Title: Exec Briefing Agent
URL: https://formationxyz.com/services/exec-briefing-agent/
Description: Build a recurring leadership brief that combines internal signals, market context, and key risks into one reviewable weekly summary.
Price: EUR5K
Billing type: recurring
Delivery window: 1 week to first briefing cycle
Team size: 2-4 people
Who to involve: Founder or executive sponsor, ops lead, and owners of the core input streams
Prerequisites: Priority data sources, reporting cadence, audience, and a clear owner for final review
Body: Problem Leadership context is usually scattered across dashboards, team notes, market signals, customer noise, and operational exceptions. That makes executive review too fragmented and slows down decision quality. Right Fit Choose this when a founder or senior team needs one reliable weekly summary rather than a growing pile of separate reports. It is a strong first agentic workflow because the inputs are known and the output is easy to review before it influences decisions. What You Get You get a recurring leadership brief that combines the inputs that matter most, highlights meaningful changes, and frames likely follow-ups. The goal is not to replace executive judgment. It is to improve the quality and speed of the context that reaches it. How XYZ Runs It XYZ defines the source set, summary structure, thresholds, and review path, then helps run the first briefing cycles until the workflow is stable. We focus on signal quality, not report volume. Choose This Instead Of Choose this when leadership needs a cross-functional weekly briefing. If the narrower need is board or investor reporting, start with Board Pack Copilot or Investor Update Engine . If the input you are missing is market visibility, Market Intelligence is a strong complement.


Title: Executive Team Agentic Sprint
URL: https://formationxyz.com/services/skills-sprint-for-senior-team-members/
Description: Run a focused sprint for senior leaders to build the judgment, habits, and operating decisions needed to lead agentic work credibly.
Price: EUR10K
Billing type: one-time
Delivery window: 1 week
Team size: 4-8 people
Who to involve: Senior team members, sponsor, operational lead
Prerequisites: Clear objectives, participating team, workflows to improve
Body: Problem Leadership teams often approve agentic initiatives without developing the judgment needed to lead them well. That creates a gap between what the company is asked to do and what leaders themselves understand about risk, workflow design, and operational reality. Right Fit Choose this when senior leaders need hands-on understanding before the wider organization changes. It fits founders and leadership teams that need better decisions around what to automate, where to keep review, and how to guide adoption. What You Get You get a focused sprint built around live company material, not abstract examples. That usually includes tested decision workflows, better prompting and review habits, clearer boundaries for automation, and a stronger shared view of what should happen next. How XYZ Runs It XYZ runs the sprint directly with the leadership group, works through real operating questions, and leaves the team with a more practical mental model for how agentic systems should be adopted and governed. Choose This Instead Of Choose this before Company-Wide Agentic Workflow if leadership judgment is the main blocker. If you already have executive alignment and need hands-on redesign with a wider team, the deeper workflow engagement is the better next move.


Title: Investor Update Engine
URL: https://formationxyz.com/services/investor-update-engine/
Description: Run investor updates through a recurring workflow so monthly updates are faster to produce, easier to review, and more consistent.
Price: EUR4K
Billing type: recurring
Delivery window: 1 week to first update cycle
Team size: 2-3 people
Who to involve: Founder, finance or ops lead, point person for investor communications
Prerequisites: Investor update cadence, source inputs, preferred format, and a review owner
Body: Problem Investor updates are easy to postpone and tedious to rebuild every month. Progress notes, pipeline context, hiring changes, product movement, and asks are all available somewhere, but the update still depends on one person pulling it together under time pressure. Right Fit Choose this when you want a standing monthly or quarterly investor-update workflow rather than an ad hoc scramble. It fits founders and operating leads who want consistent communication without turning the process into another manual burden. What You Get You get a recurring workflow that gathers inputs, drafts the update, flags missing context, and prepares the final version for review. Over time that gives you a more reliable investor communication rhythm with less rebuilding from scratch. How XYZ Runs It XYZ defines the source inputs, prompt structure, review path, and operating cadence, then helps run the first cycles until the workflow is stable. The system stays constrained around a known format and known review owner so it remains useful and safe. Choose This Instead Of Choose this when the key need is recurring investor communication. If you first need to build the reporting pack behind those updates, start with Board Pack Copilot . If you need a broader leadership brief beyond investor reporting, Exec Briefing Agent is the broader option.


Title: Pipeline Review Copilot
URL: https://formationxyz.com/services/pipeline-review-copilot/
Description: Run weekly pipeline reviews through a recurring workflow that highlights movement, risk, and stuck deals before they surprise the team.
Price: EUR4K
Billing type: recurring
Delivery window: 1 week to first review cycle
Team size: 2-3 people
Who to involve: Founder or sales leader, CRM owner, and operator responsible for weekly reviews
Prerequisites: CRM access, stage definitions, review cadence, and a clear owner for decisions
Body: Problem Pipeline reviews often happen with incomplete context and too much manual cleanup. Stage movement is hard to interpret, stuck deals get noticed late, and leadership spends the meeting reconstructing what changed instead of deciding what to do next. Right Fit Choose this when your team already has a sales pipeline and a review rhythm but wants that rhythm to become more useful. It fits founders and sales leaders who want better weekly visibility without creating another reporting burden. What You Get You get a recurring review workflow that summarizes movement, flags risk, identifies stuck deals, and prepares a cleaner decision pack for the weekly pipeline discussion. The result is less manual prep and sharper review conversations. How XYZ Runs It XYZ maps the current pipeline review process, defines what should be surfaced each cycle, and sets the workflow to gather and summarize the right information before the meeting. We keep the final judgment with the sales leader while making the prep work lighter and more consistent. Choose This Instead Of Choose this when the review meeting itself needs better inputs. If the bigger issue is follow-up after sales calls, Sales Follow-Up Operator is the better fit. If you want a broader leadership summary beyond sales, Exec Briefing Agent is the broader option.


Title: Roadmap Agentic Review
URL: https://formationxyz.com/services/full-roadmap-audit-from-an-agentic-perspective/
Description: Audit your roadmap, workflows, and operating drag to identify the highest-value AI implementation and workflow automation opportunities first.
Price: EUR15K
Billing type: one-time
Delivery window: 1-2 weeks
Team size: 3-6 people
Who to involve: Founder or sponsor, product or ops lead, technical lead
Prerequisites: Roadmap context, systems overview, access to current workflows
Body: Problem Your roadmap may already contain good ideas, but the sequence is often wrong for practical AI implementation. Teams keep funding low-leverage initiatives, manual workarounds survive for too long, and obvious workflow automation opportunities stay invisible because nobody has reviewed the roadmap against actual operating drag. Right Fit Choose this service when you need sharper prioritization before you commit to a larger build, rollout, or workflow redesign. It is a good fit for leadership teams that want clearer decisions, not a generic AI strategy deck. What You Get You get a ranked opportunity view across product, operations, delivery, and internal workflows. That typically includes a short list of workflows worth automating, candidate agent patterns, likely guard rails, and a more honest sequence for what to tackle now, later, or not at all. How XYZ Runs It XYZ reviews the roadmap, interviews the right operators, traces where work actually slows down, and compares current plans against the leverage available from AI workflows, AI integrations, and controlled automation. We turn that into concrete next moves, not vague recommendations. Expect a practical decision document your team can use for budgeting, sequencing, and follow-on implementation. Choose This Instead Of Choose this before Company-Wide Agentic Workflow or Company-Wide Agentic Deep Dive if the real problem is prioritization. If you already know the workflow you want to implement, Your Agentic Use Case is the more direct path.


Title: Company-Wide Agentic Workflow
URL: https://formationxyz.com/services/full-team-full-week-agentic-workflow-deep-dive/
Description: Run an intensive week of AI consulting and implementation with your team to redesign real workflows and make agentic automation usable in practice.
Price: EUR20K
Billing type: one-time
Delivery window: 1 week
Team size: 5-10 people
Who to involve: Cross-functional leads, sponsor, operators closest to the work
Prerequisites: Team availability, workflow access, target systems and goals
Body: Problem Teams often agree that AI should change how they work but never convert that agreement into practical AI implementation. Training stays abstract, workflows stay untouched, and nobody builds confidence because the team never redesigns live work together. Right Fit Choose this when you want a working week that changes how the team operates, not a lecture series or strategy workshop. It fits cross-functional teams that need to redesign a few important workflows and learn by doing. What You Get You get a week of hands-on workflow redesign around your real material. That usually includes mapped pain points, tested agent-supported routines, clearer approvals and handoffs, human-in-the-loop checkpoints, and a few working patterns the team can keep using after the week ends. How XYZ Runs It XYZ leads the week directly with the team, uses real workflows instead of toy examples, and captures the useful patterns as instructions, guard rails, AI integration options, or repeatable task setups. The outcome is practical experience, not just alignment. Choose This Instead Of Choose this when the main need is adoption and workflow redesign across a team. If you first need leadership-level judgment, start with Executive Team Agentic Sprint . If the problem is broader operating transformation across multiple functions, Company-Wide Agentic Deep Dive is the larger engagement.


Title: Sales Follow-Up Operator
URL: https://formationxyz.com/services/sales-follow-up-operator/
Description: Run post-call follow-up through a repeatable workflow so notes, next steps, and draft responses move faster without slipping through the cracks.
Price: EUR4K
Billing type: recurring
Delivery window: 1 week to first live cycle
Team size: 2-3 people
Who to involve: Sales lead, founder, CRM owner, and one rep or AE close to the workflow
Prerequisites: Sales call notes or recordings, CRM process, follow-up expectations, and a review owner
Body: Problem Deals slow down after the call because follow-up is inconsistent. Notes live in too many places, next steps are not captured cleanly, and good sales conversations lose momentum while the team catches up on admin. Right Fit Choose this when the team has enough sales activity that follow-up quality matters, but not enough process discipline to keep it moving consistently. It is a practical first workflow for teams curious about OpenClaw because the outcome is narrow, measurable, and easy to review. What You Get You get a recurring post-call workflow that turns notes or transcripts into summaries, next steps, CRM suggestions, and draft follow-up messages ready for review. The aim is faster response and cleaner deal progression, not unsupervised outreach. How XYZ Runs It XYZ maps the current post-call process, defines what should be captured and drafted, and sets the review boundaries before anything is sent. We then help the team run the first live cycles until the workflow is dependable. Choose This Instead Of Choose this when the biggest sales drag appears after conversations happen. If the wider need is pipeline visibility, Pipeline Review Copilot is the better fit. If the main burden is proposals and tenders, Proposal and RFP Assistant is the stronger next step.


Title: Company-Wide Agentic Deep Dive
URL: https://formationxyz.com/services/full-deep-dive-all-systems-upgraded/
Description: Redesign core systems and workflows across multiple functions with practical AI consulting, implementation, and governed automation.
Price: EUR25K
Billing type: one-time
Delivery window: 2-4 weeks
Team size: 4-8 people
Who to involve: Founder, cross-functional leads, implementation owners
Prerequisites: Decision-maker access, current systems, roadmap priorities and rollout scope
Body: Problem Some teams do not have one broken workflow. They have cross-functional drag: sales, delivery, reporting, website operations, content, and engineering all move at different speeds, rely on disconnected systems, and create friction for each other. Right Fit Choose this when you need broader operating redesign across multiple functions, not just one team or one workflow. It is a fit for founders and senior operators who want a practical transformation sequence tied to real business movement. What You Get You get a scoped cross-functional upgrade plan plus the first live operating improvements. That can include redesigned workflows, recurring reporting loops, clearer handoffs, AI integrations, agent-supported routines, and a written control layer the company can extend. How XYZ Runs It XYZ identifies the highest-value systems first, sequences the work, coaches the teams involved, and helps codify the patterns as repeatable operating components with the right human approvals and controls. The output is a small operating architecture your company can keep using, not a transformation narrative. Choose This Instead Of Choose this when Company-Wide Agentic Workflow would be too narrow or too short for the change you need. If the first decision is still where leverage exists, begin with Roadmap Agentic Review .


Title: Proposal and RFP Assistant
URL: https://formationxyz.com/services/proposal-rfp-assistant/
Description: Set up a proposal workflow that gathers source material, drafts responses, and speeds up structured bids without turning them into copy-paste chaos.
Price: EUR5K
Billing type: one-time
Delivery window: 1 week
Team size: 2-4 people
Who to involve: Sales lead, proposal owner, subject matter expert, and final approver
Prerequisites: Past proposals, common answer material, target bid types, and a review owner
Body: Problem Proposal and RFP work often burns time in predictable ways. Teams keep hunting for old answers, rewriting standard sections, and trying to keep tone and claims consistent while deadlines close in. Right Fit Choose this when your team regularly prepares proposals, tenders, or structured partner responses and wants a faster way to assemble first drafts. It is a good fit where reuse matters but accuracy and review matter even more. What You Get You get a structured response workflow with source retrieval, draft assembly, answer patterns, and review checkpoints. The result is quicker first drafts, less duplicated effort, and a cleaner answer library for future bids. How XYZ Runs It XYZ identifies the reusable source material, shapes the answer patterns, and sets up the workflow for pulling relevant context into a draft without losing human review. The system is designed to speed up the first pass, not replace final approval. Choose This Instead Of Choose this when proposals and structured responses are the bottleneck. If the recurring pain is sales follow-up after meetings, Sales Follow-Up Operator is a better first move. If your process is highly bespoke, Your Agentic Use Case may fit better.


Title: QA Tester
URL: https://formationxyz.com/services/agentic-qa-tester/
Description: Add a standing QA layer around key website and product flows so regressions and breakages are caught before they hurt customers.
Price: EUR4K
Billing type: recurring
Delivery window: 1 week to first pass
Team size: 2-3 people
Who to involve: Product owner, website or app owner, technical contact
Prerequisites: Staging or production access, priority flows, release cadence, and known risk areas
Body: Problem Important customer journeys often break quietly. Forms stop converting, release changes introduce regressions, and nobody notices until customers do because QA is too ad hoc or too understaffed to keep up. Right Fit Choose this when you need regular QA coverage around a website, app, or operational interface without building a full internal QA function first. It fits teams with recurring releases, known weak spots, or high-value user journeys that need more attention. What You Get You get a repeatable QA rhythm around the flows that matter most. That can include smoke tests, browser and device checks, release verification, issue summaries, and clearer escalation rules for what gets logged, retried, or reviewed by a human. How XYZ Runs It XYZ helps define the coverage, the cadence, and the reporting format, then sets up repeatable QA routines the team can keep using. The aim is not endless test theater. It is earlier detection, clearer reporting, and fewer avoidable issues reaching users. Choose This Instead Of Choose this when the problem is product or website quality control. If your bigger need is ongoing SEO and content maintenance, Webmaster or SEO Manager is the better fit.


Title: Marketer
URL: https://formationxyz.com/services/agentic-marketer/
Description: Turn founder knowledge, customer questions, and offer updates into a steady marketing system that keeps shipping useful content and campaigns.
Price: EUR6K
Billing type: recurring
Delivery window: 1 week to first draft
Team size: 2-3 people
Who to involve: Founder, subject matter expert, point person for approvals
Prerequisites: Clear topics, review workflow, brand voice, and access to source material
Body: Problem Many teams have real expertise and real offers but no reliable way to turn that into visible marketing. Content depends on bursts of founder energy, campaign ideas do not turn into assets fast enough, and useful customer insight dies in calls, notes, and Slack threads. Right Fit Choose this when you want consistent marketing output without building a full in-house content machine. It fits teams that already know what they sell but need a better system for turning that into articles, campaigns, landing pages, and supporting copy. What You Get You get a repeatable content and campaign workflow. That can include topic pipelines, article drafts, landing page copy, repurposed customer questions, editorial summaries, and simple approval patterns that keep output moving without lowering standards. How XYZ Runs It XYZ works with your subject matter experts, shapes the content workflow, drafts and refines the output, and sets up recurring habits the team can maintain. In practice that often means a monthly topic rhythm, reusable briefs, faster approvals, and a clearer link between what the business learns and what the market sees. Choose This Instead Of Choose this when the main gap is ongoing marketing production. If the bottleneck is website structure, start with Agentic Website . If the site is fine but content ops need to move faster, Agentic Content Management may be enough.


Title: Small Autonomous Organization
URL: https://formationxyz.com/services/autonomous-organization/
Description: Stand up a governed multi-agent team around one business function with human-in-the-loop workflows, clearer controls, and better throughput.
Price: EUR50K
Billing type: one-time
Delivery window: 4 weeks
Team size: 4-8 people
Who to involve: Founder or executive sponsor, process owner, technical lead, risk or compliance contact
Prerequisites: A clearly scoped function, source systems, operating rules, success criteria, and a responsible internal owner
Body: Problem Some business functions do not break because one task is slow. They break because too many steps, people, and handoffs have to line up every time. A single agent helps, but it does not solve coordination, QA, escalation, or ownership. Right Fit Choose this when one function such as research operations, content production, reporting, document handling, or internal service delivery needs a real operating structure, not just a prompt or helper bot. The scope should be narrow enough to own but important enough to justify governance. What You Get You get a first live autonomous operating unit for one business function. That can include specialist agents, role definitions, handoff rules, QA checks, escalation paths, human-in-the-loop controls, and a control layer that keeps the workflow moving while surfacing exceptions to humans when needed. How XYZ Runs It XYZ maps the function, defines the agent roles, designs the governance layer, and implements the first working version around your real process. We also set review boundaries, logging, reporting, audit trails, and ownership so the system can run with autonomy where it is safe and human oversight where it matters. Choose This Instead Of Choose this when you need a broader operating unit, not just one tool or one workflow. If the target function is larger, higher volume, or involves multiple coordinated streams, Complex Autonomous Organization is the better fit. OpenClaw Setup is discontinued and no longer recommended.


Title: Complex Autonomous Organization
URL: https://formationxyz.com/services/complex-autonomous-organization/
Description: Design and stand up a larger autonomous operating unit across higher-volume workflows, deeper process chains, AI integrations, and stricter controls.
Price: Talk to us
Billing type: one-time
Delivery window: Custom timeline
Team size: 6-15 people
Who to involve: Executive sponsor, operations lead, functional owners, technical lead, and risk or compliance stakeholders
Prerequisites: Target business functions, source systems, current process reality, volume assumptions, operating rules, and clear internal ownership
Body: Problem Some operating environments are too complex for a simple agent setup. Higher throughput, more exception handling, more systems, more AI integrations, and more governance requirements mean you need a designed operating structure, not a collection of disconnected automations. Right Fit Choose this when multiple coordinated workflows need to run inside one governed autonomous layer. It is a fit for organizations that have enough volume, process depth, or operational risk that architecture and controls matter as much as automation. What You Get You get a scoped design and first live implementation for a larger autonomous operating unit. That can include multiple specialist roles, shared reporting, governance logic, exception routing, system integration boundaries, human review layers, and custom orchestration where the workflow demands it. How XYZ Runs It XYZ maps the real operating model, designs the workflow architecture, decides where custom agents and AI integrations are needed, and implements the first live version around your actual process landscape. We also define review rules, escalation logic, reporting, and ownership so the system remains usable under real load. Choose This Instead Of Choose this when Small Autonomous Organization would be too narrow or too simple for the function you need to run. Because scope varies heavily by process complexity and volume, this service is scoped directly with your team.


Title: Security Officer
URL: https://formationxyz.com/services/agentic-security-officer/
Description: Add an ongoing security review layer that helps your team spot practical risks, tighten controls, and act on them faster.
Price: EUR8K
Billing type: recurring
Delivery window: 1 week to first review
Team size: 2-3 people
Who to involve: Founder, technical lead, operations owner
Prerequisites: Systems overview, current tooling, priority risks, and access to relevant environments or policies
Body: Problem Small teams usually know where some security risk exists, but the work rarely stays visible long enough to get handled properly. Access issues, weak configurations, stale processes, and unsafe habits linger because nobody owns the review rhythm. Right Fit Choose this when you need practical security improvement without hiring a full internal security function. It fits teams that want a steadier operating cadence around access, posture, workflow discipline, and obvious high-value fixes. What You Get You get a recurring security review layer tied to real operating risk. That can include access and configuration reviews, priority risk lists, operating recommendations, review cadences, and clearer rules for where automation can help safely and where human control must stay tighter. How XYZ Runs It XYZ reviews the current posture with your team, prioritizes the most important fixes, and helps establish a usable rhythm for review, escalation, and follow-through. The focus is on practical reduction of risk, not paperwork for its own sake. Choose This Instead Of Choose this when you need a standing security function in lightweight form. If the main issue is engineering delivery and tooling discipline, Engineering Team Agentic Setup may be the better starting point.


Title: Bespoke Software Project
URL: https://formationxyz.com/services/bespoke-software-project/
Description: We use agentic engineering practices to get you high quality solutions fast, from apps and websites to geospatial systems, search, and product intelligence.
Price: Talk to us
Billing type: one-time
Delivery window: Custom timeline
Team size: 2-6 people
Who to involve: Project sponsor, product or workflow owner, technical stakeholders
Prerequisites: A clear business objective, the target system or workflow, and access to the current technical context
Body: Problem Some teams do not need a packaged service. They need a real software project delivered quickly, with strong engineering discipline and agentic workflows that compress research, implementation, review, and iteration. Right Fit Choose this when the outcome is a concrete software asset rather than a workshop or narrowly scoped operator. It fits apps, websites, internal tools, geospatial systems, search upgrades, and intelligence features that need custom implementation. What You Get You get a bespoke software delivery engagement shaped around the system you actually need. That can include product framing, technical design, rapid implementation, search and intelligence features, geospatial capability, and production-ready handoff. How XYZ Runs It XYZ uses agentic engineering practices to move from brief to working software faster without dropping review discipline. We use practical guard rails, iterative delivery, and tight feedback loops so the project stays aligned with the real business problem. Choose This Instead Of Choose this when none of the named services covers the delivery scope, or when the work cuts across product, engineering, web, search, or location systems. If the need is still a single undefined workflow rather than a broader build effort, Your Agentic Use Case is the better starting point.


Title: Meeting Prep and Decision Pack
URL: https://formationxyz.com/services/meeting-prep-decision-pack/
Description: Prepare high-stakes meetings faster by pulling together notes, prior decisions, open issues, and a reviewable pre-read in one workflow.
Price: EUR4K
Billing type: one-time
Delivery window: 4 days
Team size: 2-3 people
Who to involve: Meeting owner, executive sponsor, and whoever currently assembles the prep material
Prerequisites: Recurring meeting type, source documents, prior decisions, and a clear review owner
Body: Problem Important meetings often start with weak preparation. Context is split across notes, docs, email threads, and chat, so people arrive with different versions of the problem and waste time reconstructing what should already be clear. Right Fit Choose this when you have recurring strategic, investor, sales, or operating meetings that would improve materially with better prep. It is a good entry workflow because the output is narrow, reviewable, and directly tied to decision quality. What You Get You get a prep workflow that gathers source context, surfaces prior decisions and open issues, and assembles a clear pre-read or decision pack for review. The result is stronger preparation with less manual hunting and stitching. How XYZ Runs It XYZ maps the prep process, defines the source inputs and format, and builds the first workflow around a real meeting type your team already runs. We keep the summary constrained and reviewable so it improves preparation without introducing ambiguity about ownership. Choose This Instead Of Choose this when the main issue is meeting preparation and decision context. If the recurring need is a broader weekly leadership summary, Exec Briefing Agent is the better fit. If the process is diligence-heavy and document-intensive, Due Diligence Room Assistant is closer to the real need.


Title: Your Agentic Use Case
URL: https://formationxyz.com/services/your-agentic-use-case/
Description: Bring the workflow, bottleneck, or AI use case that needs custom AI implementation, workflow automation, or human-in-the-loop design.
Price: Talk to us
Billing type: one-time
Delivery window: Custom timeline
Team size: 2-4 people
Who to involve: Workflow owner, subject matter expert, technical or operational contact
Prerequisites: A clear problem, target workflow, or use case idea plus access to the current process reality
Body: Problem Not every useful AI workflow fits a productized package. Teams often have one high-value bottleneck or one clear use case in mind, but they need help turning it into something scoped, governed, and practical enough to implement. Right Fit Choose this when your problem is specific and real but does not map neatly to one of the named services. It fits teams that know the target workflow or business pain and want help shaping the right implementation. What You Get You get a scoped service definition around your use case. That can include workflow design, tool selection, AI integrations, guard rails, review rules, recurring task setup, and a practical implementation path tied to the real process. How XYZ Runs It XYZ works with your team to define what the workflow should do, what boundaries it needs, where human-in-the-loop checks belong, what setup fits best, and what the first production-ready version should look like. The aim is to turn a good idea into an operating service quickly. Choose This Instead Of Choose this when none of the named packages fits well enough. If your need is broader website work, market intelligence, or engineering adoption, the dedicated services in those categories will usually be a faster start.

## Blog articles
Title: Custom software is back for smaller companies
URL: https://formationxyz.com/blog/custom-software/
Published: 2026-07-06
Author: XYZ by FORMATION
Description: LLMs have made custom internal software cheaper to build, but complex workflows still need hands-on AI implementation, data work, and engineering discipline.
Body: For the last twenty years, most companies solved software problems by buying SaaS. That was usually the sensible choice. Custom software was expensive, slow, and risky. Unless a workflow was strategic enough to justify a full project, the practical answer was to buy the product that came closest and adapt the company around it. The result was the SaaS model we all know. One product serves thousands of companies. Every customer gets roughly the same interface, data model, workflow logic, and opinion about how the work should be done. There may be custom fields, integrations, settings, and a few personalization options. But the basic deal is simple: your company uses the same product as everybody else. That tradeoff made sense when software production was the expensive part. LLMs are changing the tradeoff. It is now much easier to create software for one company, one team, or one very specific workflow. A useful internal tool no longer needs a venture-backed product team behind it. It does not need a public roadmap, a marketplace listing, or a pricing page. It only needs to solve the problem inside the company that will use it. That opens a real opportunity for small and mid-sized companies. The old custom software model was too heavy Custom software used to mean a large project before the first useful version appeared. There would be scoping, design, engineering, infrastructure, testing, rollout, support, and the permanent question of who would maintain it. For many companies, the answer was simple: do not build unless there was no alternative. SaaS won because it removed most of that burden. You paid a subscription, accepted the product’s assumptions, and got moving. Even if the fit was imperfect, it was usually better than paying for a bespoke system from scratch. Many internal workflows now sit inside tools that are almost right. The CRM almost fits the sales process. The project tool almost fits the delivery model. The finance template almost fits the costing logic. The reporting dashboard almost answers the actual management question. The team learns the gaps, creates workarounds, and treats the friction as normal. LLMs make that normality less acceptable. If a team can now build a narrow tool much faster, the question changes from “Can we afford custom software?” to “Is this workflow specific enough that custom software would be better than another compromise?” We looked at the related buy-versus-build risk in Should We All Now Build Our Own Internal Tools with AI? . Vibe coding will create many useful tools There is nothing wrong with people building small tools for themselves. Vibe coding is useful. A founder can build a small dashboard. An operations lead can create a document helper. A finance person can prototype a pricing calculator. A sales team can create a quick account-research workflow. The threshold for turning a recurring irritation into a working tool has dropped sharply. Companies should experiment. People who understand the work often know exactly where the friction is. If they can create a first version themselves, they can test whether the idea is useful before anyone turns it into a larger project. The problem starts when the workflow stops being simple. A prototype that helps one person with one task is different from a system that handles real company data, carries business logic, supports approvals, produces outputs others rely on, or drives downstream processes. At that point, the work is no longer just “make an app.” It becomes product design, data modelling, software engineering, security, operations, and change management. That is where many vibe-coded internal tools will hit a wall. It is the same judgment problem behind Everybody is a developer now. What happens next? : producing software artifacts is getting easier, but architecture, security, UX, data, and operational control still matter. Complex workflows still need professional structure Some jobs are funny to start yourself and expensive to finish badly. Internal software has the same failure mode once real data, approvals, and downstream decisions are involved. The most valuable internal tools are rarely simple forms with a nice interface. They often involve data pipelines, messy inputs, human review, multi-step processes, exceptions, permissions, calculations, and downstream actions. They may need to clean data from several systems, classify records, run analysis, support costing, generate documents, update a CRM, or prepare decisions for a manager. That kind of work is not easy just because an LLM can write code. The hard part is knowing what the system should mean. Which data source is authoritative? Which fields matter? What happens when a value is missing? Which steps can be automated? Where does a human need to approve? How should the tool explain its result? What should be logged? What happens when the API changes? Who owns the workflow after launch? These questions are not implementation details. They are the product. A team can vibe code its way through the first visible layer and still be stuck with the harder parts untouched. The interface exists, but the data model is weak. The demo works, but the edge cases fail. The calculation looks right, but nobody knows how to audit it. The first user loves it, but the second team cannot use it without changes. The tool gets close enough to be exciting, then becomes too fragile to trust. That is the brick wall. The way around it usually looks more like code-centric AI workflows and closed-loop systems : structured inputs, reviewable changes, tests, logs, and controlled feedback loops around the work. The sweet spot is professional custom software built with LLMs There is a middle way between old custom software and unmanaged internal experiments. Use LLMs to move fast, but have professionals design and build the tool. This is where AI consulting and implementation becomes more useful than advice alone. That means a team comes in, learns the workflow, maps the data, identifies the decision points, and builds software around the specific way the company actually works. The tool does not need to serve a market category. It does not need to please every possible buyer. It only needs to fit this company, this process, this data, and this group of users. That is a much easier target than building generic SaaS. Generic SaaS has to support many customers, edge cases, integration patterns, permission models, onboarding paths, and conflicting opinions about how the work should be done. Custom internal software can be more focused. The users are known. The workflow is known. The business rules can be explicit. The first version can be small, useful, and built around actual operating context. LLMs make that approach commercially realistic for more companies. They reduce the cost of implementation, speed up iteration, and make it easier to move from understanding the workflow to a working tool. But they do not remove the need for judgment. The value comes from combining the new speed of LLM-assisted development with product and engineering discipline. Is this the beginning of the SaaSpocalypse? For some SaaS companies, yes. Low-value SaaS is vulnerable. If a product is mostly a thin workflow wrapper, a generic dashboard, or a slightly awkward process tool, customers will increasingly ask whether a custom internal version would fit better. But SaaS will not disappear. Strong SaaS products still have advantages. They serve large audiences with shared needs. They absorb regulatory, security, infrastructure, support, and maintenance work. They benefit from network effects, integrations, and product maturity. If a SaaS tool does exactly what a large audience wants, it will keep being useful. The pressure is higher where SaaS owns the workflow too tightly. That is the problem we described in Agentic De-Siloing: Moving Work Out of SaaS Silos : companies need more control over the data, rules, and operating memory that agents and internal tools depend on. The bigger change is the arrival of a new category. Small and mid-sized companies can now commission internal tools that would previously have been too expensive to justify. These tools sit between SaaS and traditional bespoke software. They are custom, but not bloated. They are fast to build, but not casual. They are specific, but still professionally designed and maintained. That is a glimpse of where software is going. More tools will be built for specific people, specific teams, specific partner groups, and specific companies. One-size-fits-all software will still exist, but it will no longer be the only realistic option for many company workflows. Build around the company, not the category The important question is not whether a company should build everything itself. It should not. The question is where the work is specific enough, valuable enough, and awkward enough that a custom tool would create a better operating model than another SaaS compromise. Good candidates often have a few things in common: the workflow is repeated often the current tool fit is poor the process depends on company-specific knowledge the data comes from several places the output drives real decisions or downstream work the team already has manual workarounds the value of a better fit is easy to explain Those are the workflows where custom internal software can create leverage. At XYZ, this is exactly the kind of work we are interested in. We are already working on active cases where LLM-assisted development makes it possible to move quickly, while still treating the data, workflow, and support model seriously. If your company has a specific internal workflow that never quite fits standard software, get in touch or book a meeting . We can help you work out whether a custom tool makes sense, what the first version should do, and how to build it without turning a useful idea into unsupported internal software.


Title: Without Knowledge, AI is powerless
URL: https://formationxyz.com/blog/without-knowledge-ai-is-powerless/
Published: 2026-06-24
Author: XYZ by FORMATION
Description: AI agents need company-specific knowledge before they can handle proposals, support, reporting, contracts, and internal workflows with enough context to be trusted.
Body: To answer questions about your company, projects, or domain, AI Agents need access to the relevant information. Attaching a PDF to a ChatGPT conversation works up to a point. Using plugins or connectors with Claude, Cowork, or Codex works a bit better. It is still not enough. AI models are trained on public knowledge. When they do not know something, they use tools and search engines to find it. The answer is only ever going to be as good as the information they can gather. If they cannot find what they need, their answers and actions will not be good enough. Companies actually have a lot of data and knowledge. It is just squirreled away in archives, awkward file formats, books, company drives, old tickets, project folders, and tools that were never designed for agents. Even people struggle to navigate that maze. An AI with generic API access to email, Google Drive, and a few SaaS tools will struggle too. Give Agentic AIs the company facts and they can do impressive things. Starve them of context and even a model solving Nobel Prize-level problems becomes useless inside your business. The model is not the bottleneck. The knowledge is. Knowledge Bases Provide Operating Context A common solution in AI workflows is a knowledge base: a data store with a search engine in front of it. Modern information retrieval systems can do semantic search. They can look beyond keywords and take meaning into account. This can work for text, images, documents, tickets, and other company material. We are all used to good search when we use Google. But Google does not cover your company data. Many SaaS tools have search APIs, but they usually do not understand how your company organizes information, which version is final, which document is a draft, which customer record matters, or how different pieces of information relate to each other. Getting Accurate Facts Without Blowing Through Your Token Budget When presented with a complex question and guard rails, AI Agents can query the data store, gather relevant information, and attach it to their context. This is Retrieval Augmented Generation, or RAG for short. A lot of AI workflow products are built around RAG and vector search for a good reason: this is how they unlock company knowledge. Conceptually, RAG is search. Any decent search engine can be used for it. The hard questions are practical: can it find the relevant information, rank it properly, and dig out the best version of what the agent needs? Modern AI models have huge context windows, so they can make sense of a lot of material. But context costs tokens. If search is lousy or slow, agents compensate by gathering too much and trying to reason through the pile. The more they gather, the more expensive and noisy the workflow gets. Knowledge Bases Are The Leverage Point A well organized knowledge base changes the economics of agentic work. If agents struggle to find what they need, they are slow and ineffective. Give them clean, relevant, well-ranked knowledge and many niche company problems become tractable. That is the work FORMATION XYZ does. Jilles van Gurp, the CTO behind FORMATION XYZ, has worked with information retrieval systems for over two decades. Across his career, he has used search frameworks like Apache Lucene and products such as Elasticsearch and Solr to build domain-specific search engines for clients and startups. Lately, that includes vector search. He also created the search library that powers search on this website. Our mother company FORMATION relies heavily on search as well. The Spatial Intelligence platform turns location and spatial context into operational knowledge for workers in factories. That work was the spark for FORMATION XYZ. If we can do this for factory workers, why not do it for everyone else? Creating And Maintaining The Knowledge Base The FORMATION approach starts from value, not from a tool demo. What questions does the knowledge base need to answer? What does the team need to do? Which information exists already? Which parts are authoritative, stale, duplicated, private, or simply noise? There are no shortcuts here. No magical download lets you skip understanding the company. We have to map the processes, the people, the documents, the decisions, and the knowledge that makes the business work. Then we build prototypes and run data experiments. We look for the right structure, the right search approach, and the right level of curation. Sometimes that means extracting fields from messy documents. Sometimes it means tagging product lines, normalizing customer names, filtering old versions, or enriching records so agents can use them safely. This often leads to automated data pipelines. In plain English: take raw company information, clean it up, reshape it, and load it into the knowledge base in a form that works for RAG. This is not a one-time job. The company needs to own the knowledge base over time. Your workers and AI Agents can only be as good as the knowledge they have at their disposal. Building Agentic Workflows Once the knowledge layer works, we map processes and design Agent Workflows around them. Agents are tool-using AIs. They can manipulate documents, call deep into APIs, update systems, and affect the real world. That has to be constrained with guard rails. Guard rails keep the right people in the loop, especially at decision points where an agent should not act alone. They also prevent agents from doing the wrong thing quickly and confidently, which is the nightmare version of automation. How FORMATION XYZ Helps A lot of companies are trying to make sense of the hype and get value out of the AI tools available to them. Business leaders are anxious about missing out, falling behind, or watching competitors move faster. AI FOMO is very real. We can help. We are senior product designers, information retrieval experts, and we know how gnarly the real world can be for companies. Our way is not pushing you onto a tool. We work with your team to figure out what is needed, what to build, what to borrow, what to keep, and what expectations are realistic. If your company is ready to turn scattered internal knowledge into practical AI workflows, contact us . We can help identify the highest-value use cases, design the knowledge base, and build the retrieval and ETL processes needed to support agents that work with your business context.


Title: Launching Agentic Mail
URL: https://formationxyz.com/blog/launching-agentic-mail/
Published: 2026-06-23
Author: XYZ by FORMATION
Description: Agentic Mail is our email-first support MVP. Send it a real question and see how it answers from source material.
Body: We just launched the first public MVP of Agentic Mail. You can try it out by sending an email to mail-agent@formationxyz.com . The mail agent will reply with an answer in a few minutes. The scope of the agent is narrow. It knows how to answer questions about FORMATION XYZ based on this website. You can ask questions about our services, MVPs, blog posts, team, or how we work. Most companies already have the source material their customers need: websites, docs, FAQs, help articles, onboarding notes, policies, and release notes. The agent retrieves that material before it answers. If the source material is thin, missing, or outside scope, it will say so. It can also choose to escalate to a person in our team by CCing the relevant person. It should do so for pricing requests or things it can’t answer. We’ve given the email agent a limited amount of credit. We’re, of course, carefully monitoring any interactions to see how we can tighten our RAG queries, guard rails, etc. And since we are in Germany, we will of course honor any GDPR-related requests to remove data. Email works for this MVP because the useful facts are boring: No signup is needed. People can simply send a message. Almost everyone online knows how to send email. There are billions of email users. Email conversations are authenticated enough for many support workflows. Login flows often prove account ownership by sending a link or code to an inbox, and companies already use email addresses as customer handles. A fresh incoming email is not enough on its own because mail headers can be forged. But subsequent replies that include information sent by the agent confirm receipt and practical control of that inbox. Many company processes already run through email. Threads, forwarded messages, attachments, and CCs carry useful structure and context for an agent to work with. First-line AI replies can handle questions that are answerable from existing material, so people can focus on cases that need judgment or more help. The email agent can also solicit more details before escalating to the right support person. Ideally, it can handle the request autonomously. Our goal is to test out the service with real users and gather feedback. We want to see what people ask, where the answers are useful, where the agent gets stuck, and what needs to be clearer. And of course, we need to dial in guard rails and test how well the agent stays on track. Also, we want to identify early customers interested in setting this up for their website, product, or service. Please contact us if that sounds interesting to you. You can read more about our new service here . Do reply to this email! If you are not on the newsletter yet, sign up on the front page . This newsletter is sent from the email address of our mail agent. When you receive our newsletter, you can engage with the agent simply by replying to it. If you want your own mail agent for your documentation, product, website, or internal knowledge, contact us. We can set it up around your source material, scope, and escalation rules. Try it now: email mail-agent@formationxyz.com .


Title: Agentic De-Siloing: Moving Work Out of SaaS Silos
URL: https://formationxyz.com/blog/agentic-de-siloing/
Published: 2026-06-10
Author: XYZ by FORMATION
Description: Agentic de-siloing moves operational data out of closed SaaS systems and into open, structured, reviewable workflows where LLMs can work closer to the data with stronger control.
Body: For years, many companies have treated SaaS tools as the natural home for their operations. Projects live in one product. Chat lives in another. Roadmaps live somewhere else. Documents, customer notes, meeting decisions, tasks, and reporting all end up scattered across vendor systems with different permissions, exports, APIs, and data models. That worked well enough while the main user was a person clicking through a browser. It works less well when the next user is an AI agent trying to understand the current state of the company, update records, compare priorities, prepare a report, or move a workflow forward under review. Agentic de-siloing is the process of moving important operational data out of closed SaaS silos and into open, structured, reviewable systems that agents can work with directly. SaaS remains useful. Dependency is the issue. When the operating memory of a company sits inside tools that are hard to inspect, hard to version, hard to query, and hard to connect to agentic workflows, the company has less control over its own work. At FORMATION, we recently made that tradeoff concrete. We dropped Slack for Matrix. We dropped Asana for a Codex-centered roadmap workflow. The larger pattern is simple: move communication and roadmap data closer to open source and source-controlled systems, then let agents operate on that data with clear rules, audit trails, and human approvals. Apple's 1984 commercial is a useful cultural reference for this article because it gave the screen-breaking image a lasting place in technology culture. Here, the metaphor is about breaking operational data out of closed SaaS silos. Why SaaS silos are becoming a bigger problem The old SaaS model assumes that the application owns the workflow. The tool gives you the interface, the data model, the notification logic, the permissions layer, the export options, and the automation surface. You adapt the business around the product. If the product fits well, this can be efficient. If the product only partly fits, the team starts building workarounds. Those workarounds are familiar. People add custom fields that only one person understands. They paste long context into comments because the data model cannot express what they need. They create boards that become stale because updating them takes too much manual effort. They export CSV files for analysis, then lose the connection between the analysis and the source. They keep the real decision in chat because the project tool feels too rigid. AI exposes the cost of that fragmentation. An agent can only help reliably when it can see the right context, understand the structure, make controlled changes, and leave behind a reviewable result. A closed or awkward SaaS system adds friction at every step. The agent may need a brittle API integration. It may only see partial records. It may not understand the team’s conventions. It may be unable to version a change, run checks, or explain what changed in a form the team can review. Workflow automation inside existing operations needs a better substrate. The data should be readable. The structure should be explicit. Changes should be trackable. Sensitive actions should require human approvals. The system should support audit logs and observability without requiring a large platform program. This is where AI consulting and implementation has to move beyond advice and into operating design. What we changed The first visible change was chat. We moved from Slack to Matrix because we wanted team communication to live in an open protocol that is easier to integrate with agents. Matrix gives us a self-hostable, open source communication layer with real room structure, bot users, and a better foundation for agentic automation. We can connect agents to conversations, create rooms, manage bot identities, and keep more control over the operating surface. The second change was roadmap work. We had used Asana for years. It held a lot of project and roadmap memory, but the data lived inside a product interface that was not ideal for the kind of AI operations we now want. We exported the data, enriched it using our YAML method, stored it in Git, and made it available to Codex. That shifted the roadmap from a SaaS board into a structured operating asset. In practical terms, we replaced Asana with Codex as the place where roadmap work gets queried, organized, reviewed, and improved. The YAML layer gives each item a clearer shape. A roadmap item can carry fields such as owner, status, area, priority, dependencies, customer relevance, decision notes, risks, and next action. Git gives us version history, diffs, branches, reviews, and rollback. Codex can inspect the files, reorganize them, query across them, prepare summaries, update structures, and propose changes. We can now ask questions that were awkward before: Which roadmap items are blocked by the same dependency? What changed since last week? Which ideas are still vague and need product judgment? Which tasks have no owner? Which items connect to current sales conversations or customer needs? Which roadmap themes are growing without a clear decision? We can also reorganize the roadmap without waiting for a vendor feature. If we want a view by customer impact, strategic theme, technical risk, delivery owner, revenue relevance, or implementation stage, the data is already in a form agents can work with. Why Git changes the operating model Git is useful here because it makes operational change reviewable. In a SaaS product, a task change often becomes a quiet mutation inside a database. Someone changes a field, drags a card, edits a description, or deletes a comment. The history may exist somewhere, but it is rarely the main operating surface. In a Git-based workflow, change becomes explicit. A proposed roadmap cleanup can be shown as a diff. A larger reclassification can happen on a branch. A weekly planning update can be reviewed before it lands. A mistaken edit can be reverted. The structure of the work can evolve over time without losing the trail of how it changed. That matters for AI implementation. Agents are good at reading structured files, comparing versions, editing consistent formats, and following repository instructions. They can work inside a controlled environment with clear permissions and review steps. They can create a pull request instead of silently changing the source of truth. They can explain the change in plain language and show the exact lines affected. This is one reason code-centric AI workflows are becoming relevant beyond software engineering. Nobody needs to turn every operator into a developer. More business work should live in systems that are inspectable, scriptable, versioned, and safe for agents to operate on. Bringing data and LLM processing closer together Many AI integrations still treat the LLM as an outer layer. The model sits beside the SaaS stack. It receives copied text, a partial export, or a connector-mediated view of the data. It writes a summary or drafts a response. Then a person has to paste the output back into the system of record. Agentic de-siloing changes the architecture. The data and the LLM processing move closer together. The model can inspect the source files, use the same structure every time, apply local rules, run narrow checks, and prepare changes in the place where the data already lives. This reduces manual work and improves team leverage because the agent does not need to reconstruct the operating context from scratch. The context is already encoded in the data model, the file structure, the instructions, and the review process. The same pattern can apply beyond roadmap work: Meeting notes can become structured decisions and follow-ups. Sales conversations can become reviewed next actions and account updates. Website work can become promptable content and SEO operations. Investor updates can become recurring reporting data. Support themes can become product signals. Security reviews can become tracked risk items with owners. Each workflow needs its own controls. Some changes can be proposed freely. Some require approval. Some should never be automated. Good AI workflow automation depends on approvals and escalation rules, audit logs, and operational reliability. The practical lesson Small teams should avoid trying to replace every SaaS tool at once. Start with one workflow where the data is valuable, repeated, and trapped. Look for a place where people keep exporting, copying, summarizing, reformatting, or asking the same status questions. Map the process. Define the fields. Move a first version into a structured format. Add human-in-the-loop review. Let an agent help with organization, cleanup, reporting, and controlled updates. The first win is usually clarity. The team can see the work again. The second win is flexibility. The same data can support different views without being locked into one vendor’s interface. The third win is compounding. Every improvement to the structure, instructions, and review process makes the next agentic workflow easier. For us, moving from Slack to Matrix and from Asana to Codex is part of a wider operating model. We want practical AI systems that connect tools, data, and teams with less manual coordination. We want working software, not slide decks. We want automation systems with enough control that people trust them in daily work. That is the real promise of agentic de-siloing. It gives the company more ownership over its operating data and gives agents a better place to work. If your team is sitting on years of roadmap, project, customer, or operations data inside disconnected tools, the next useful step may be a workflow audit . Identify which data should stay in SaaS, which data should move into an open model, and which agentic workflows become possible once the source of truth is easier to inspect, query, and improve. This is a practical entry point for AI consulting in Berlin, especially for small teams that want AI systems integrated into existing tools and data without adding another silo.


Title: My Agentic Inbox Is Awesome
URL: https://formationxyz.com/blog/my-agentic-inbox/
Published: 2026-06-04
Author: XYZ by FORMATION
Description: Email used to be a chore, a time drain, and sometimes a small daily nightmare. My agentic inbox has turned it into an organized workflow I can actually trust.
Body: Email used to be a chore. Some days it was a time drain. Some days it was a small nightmare. That has changed. I now have a fully organized agentic inbox experience, and I want everyone who lives inside business email to have something like it. It feels calmer, cleaner, and more useful. The inbox is no longer a place where I lurk between tasks, waiting for the next thing to interrupt me. It is a workflow that helps me review, prioritize, draft, follow up, clean up, and prepare. Not because each message was hard. Most individual emails are simple enough. The problem is the fragmentation. One useful detail is in a recent thread. Another is buried in a reply from three months ago. A promised follow-up is hidden under a newsletter. A meeting needs a calendar invite, an agenda, a short note, and three people copied in. None of this work looks large when viewed one email at a time, but it adds up. I now use an agentic inbox workflow for that work. It gives me a morning digest, an evening digest, and a weekly digest. It helps me draft replies. It finds opportunities where I dropped the ball, where someone else forgot to follow up, or where a promising conversation simply faded away. It lets me dictate longer instructions by voice instead of trying to type a careful email from scratch. It can cross-reference old threads and pull fragmented information back into a useful shape. The inbox has gone from a place I monitor to a workflow I direct. The Daily Digest Changed the Habit The biggest change is simple. I do not sit in my inbox waiting for the next message in the way I used to. Each morning, I get a digest of the emails that need attention. It separates urgent items from important but less urgent items, then groups the rest into lower-priority context. It also has an ignore section for newsletters, spammy marketing, and other things that do not need real attention. That matters because most inboxes train people into a bad habit. You check, react, sort, skim, forget, search again, and lose the thread. The digest changes the shape of the work. I can review the day, decide what needs action, and then ask the agent to help with the actual follow-up. The evening digest catches loose ends before the day closes. The weekly digest helps surface bigger patterns: deals that have gone quiet, conversations that need a nudge, and admin threads that are still waiting on some missing detail. The Inbox Became a Sales Tool Email is not just correspondence. For many companies, it is where sales and business development actually happen. That also means it is where opportunities quietly die. Someone asks for a proposal. A meeting goes well. A contact says to follow up in two weeks. Then the thread disappears below daily noise. Nobody meant to lose it, but the business still loses momentum. The agentic workflow can trawl the inbox for exactly those cases. It looks for stalled opportunities, unanswered replies, open loops, and conversations where the next action is implied but never completed. I have reactivated a meaningful number of conversations this way. This is especially valuable for people managing several inboxes. We recently spoke with a principal at a large investment firm in Berlin who was handling six inboxes. At that point, the work is not just email management. It is operational risk. A good agentic inbox could easily give that kind of person back a material part of the working week. Voice Makes Long Replies Easier Some emails are hard to type because the instruction is more complicated than the message itself. I often know exactly what I want to say, but writing it out requires context, tone, references, caveats, and attachments. Voice dictation changes that. I can explain the intent out loud: who the reply is for, which threads matter, what needs to be included, what should be left out, and what tone is appropriate. The agent turns that into a draft. I still review it. I still approve it. But I am no longer starting with an empty message window and a stack of open tabs. For long, context-heavy replies, that is a practical difference. A Real Example: Invoice From Fragmented Threads One recent task made the value very clear. I needed to construct an invoice and an offer from information scattered across several email threads. Some of the threads were old. The relevant details were fragmented across different messages, contacts, and dates. Doing this manually would have meant searching the inbox, reopening threads, reading old context, copying details into a working note, checking the commercial terms, and then building the actual documents. That could have taken most of a day. Instead, I dictated the instruction. I asked the agent to cross-reference the relevant threads, pull the facts together, formulate the new thread, and structure the data needed for an offer and invoice. From there, I used DECK/DOCS, which we covered in an earlier post, to create a new offer document and invoice document. Both were generated in the house style. The metadata came from the email context. The terms, contacts, scope, and supporting details were traceable back to the source threads. I then did a quality-control pass with Codex. It checked the assembled material against the source context and helped identify anything that needed human review. The whole task took about 25 to 30 minutes. That is the difference between email as admin overhead and email as structured operational input. It Also Cleans the Noise The workflow is useful for important emails, but it is also useful for everything that should disappear. The digest shows newsletters, spammy messages, low-value updates, and recurring noise in a separate section. From there, I can create rules, unsubscribe, or tell the agent how to handle that kind of message in the future. This has made the inbox cleaner over time. That is important. A useful inbox workflow should not only help you process more. It should reduce the amount of low-value material that reaches you in the first place. Email Connects to Calendar, Drive, and Meeting Prep Email rarely stays inside email. A reply often needs a meeting. A meeting needs an invite, participants, context, and an agenda. A meeting the next day needs preparation. The same agentic pattern works there too. We now use meeting digests for upcoming calls. They brief us on who we are meeting, why the meeting exists, what the relevant context is, and what agenda would make sense. When a reply needs a meeting, the workflow can also prepare the calendar invite, add the right people, populate the agenda, and send the invite once approved. The workflow is also connected to our Drive, so it can use relevant documents instead of relying only on the current email thread. That matters when the context lives across an offer document, a shared brief, an old PDF, a pricing note, and a few scattered emails. Video call transcripts are becoming another useful layer. Most video calls now produce a transcript. That transcript is not just a record. It is source material for follow-up emails, tasks, calendar bookings, proposal updates, meeting notes, and account context. Once that material is available to the workflow, the handoff after a call becomes much cleaner. That removes a lot of small coordination work. More importantly, it keeps the context intact as work moves from email to calendar to meeting to Drive to follow-up. This Is Where Email Is Going Email is still where a lot of business happens. It is also one of the most fragmented systems most companies run. An agentic inbox does not replace judgment. It does not remove review. It does not make every message automatic. The value comes from giving the agent the repetitive, context-heavy, search-heavy, formatting-heavy parts of the job, while the person keeps control of decisions, tone, claims, and approval. The working style feels genuinely new. Dictating instructions by voice feels closer to briefing a personal assistant than using a normal software tool. You probably need a private place to do it unless you want some odd looks, but the difference is real. It is often easier to think clearly when you can explain the task out loud: find this context, compare these threads, prepare that reply, create the calendar invite, check the document, and flag anything uncertain. That is the direction this is going. Not one agent doing magic, but a high-functioning assistant or a small team of assistants, each handling a bounded loop and handing work back for review. Email connects to calendar. Calendar connects to meeting prep. Meeting prep connects to transcripts. Transcripts connect to follow-up. Follow-up connects to documents, offers, invoices, and CRM work. For small, lean teams, that is a very welcome change. The goal is not to automate away the relationship, the judgment, or the substance of the work. The goal is to automate away the dull administration around it, so more attention goes to the content of the meeting, the relationship with the person, the details of the deal, and the quality of what you are actually offering. For me, that has changed email from a chore into a business development system. It also gives a very clear glimpse of how agentic loops will start to connect across the rest of business operations. XYZ is already advising companies on this. If you want an agentic inbox, drop us a line. If you are in Berlin, come visit us at Delta Campus and we can talk through what this could look like in your own workflow. We also have some very interesting email and agent updates coming soon.


Title: We're using OpenClaw, it sucks!
URL: https://formationxyz.com/blog/were-using-openclaw-it-sucks/
Published: 2026-06-02
Author: XYZ by FORMATION
Description: We have been using OpenClaw for real agentic workflows and team collaboration. It makes some important ideas accessible, but the product is flaky, slow, insecure, and structurally hard to trust.
Body: We started using OpenClaw a few months ago to explore agentic workflows. At the beginning of the year OpenClaw represented the cutting edge on this front. It answers the question of what happens when you just give AIs full access. The answer is a lot of interesting, positive things. And possibly a few really bad things as well. The name is appropriate because it is a tool with some sharp, pointy edges that can and will draw blood when used in anger. This article is mostly about how we set it up and why it sucks. And it has a happy ending because better tools are becoming available! How We Set It Up One of the first things we did, after experimenting with Slack and WhatsApp, was to set up Matrix. Matrix is an open-source alternative to Slack, but the more important difference is that it gives you much richer access. Slack is heavily locked down. Adding bots means stepping through a ridiculous permission maze, and a lot of it is manual. Every time you want to add or adjust something, Slack reminds you who is in control. Matrix is a lot more open. If you run your own setup, you can give an agent full admin access and let it do real work. So that is what we did. We gave OpenClaw full admin access to our Matrix setup. OpenClaw has a concept of agents. Each agent gets its own work directory, its own files, its own skills, its own tools, and its own agentic loop. That part is good. It gives you a workable mental model for creating specialised actors instead of one giant general-purpose assistant trying to do everything. The first agent we created was called ClawdAdminime. Its job is to administer our OpenClaw setup. It can create Matrix rooms, create Matrix bot users, invite people into rooms, and set up the OpenClaw Matrix bot user connection for each new agent. That means I can prompt it with something like “create an agent called X” and it will go off and provision the room, invite the relevant people, and leave the bot ready to respond. That is genuinely useful. It compresses a bunch of annoying setup steps into one request. It also shows what these systems are supposed to become: operational layers that take care of recurring admin work, not just chat toys that sit on the side of your workflow looking clever. Why OpenClaw Sucks It self-destructs on a regular basis. It’s a fast-moving project with lots of updates. OpenClaw ships frequent updates and releases. That sounds good until you realise that almost every release seems to break something. Configuration changes, new features, an extra permission that is missing, etc. All the channels I have tried are a bit wonky and flaky in different ways. With the WhatsApp integration, you basically end up having a schizophrenic chat with yourself because OpenClaw posts its replies as you. Yes, you can work around that with multiple phone numbers. Slack is bad for a different reason. The product itself is fine for people chatting, but it is a complete pain to integrate with. You end up having to micro-manage a huge list of scopes and access rules. And you have to do this manually in a UI that is barely fit for purpose. It seems Slack has lost the plot when it comes to agentic AIs. This is the main reason we switched to Matrix. Matrix is great. Everything we liked about Slack but without the limitations, cost, etc. The OpenClaw integration with Matrix unfortunately is a bit flaky. It works great, for a while. And then it will stop responding and you have to debug why. If you leave OpenClaw alone for a few days, there is a decent chance it will stop working. Fighting AI flakiness with more AI I used to fix these things manually, but I gave up on doing that. It’s just too much. These days I let Codex deal with figuring out how to fix things. It will dutifully dig through logs, issue trackers, etc., and it will do an accelerated version of “bang on it until it works again” that you would otherwise have to do manually. I’ve actually set up a Codex automation to do this on a schedule now. It checks in on our OpenClaw server every morning and kicks it back into shape again. But of course this flakiness is a show-stopper issue. First, even if you do know how to fix things, it is still annoying to have to do it. And most business users would of course get stuck on the first issue. You can’t organize your life around something this poorly engineered. OpenClaw is slow. OpenClaw is not just flaky. It is also very slow. Slow to wake up. Slow to construct a context and eventually call a model. And then slow to funnel the answer back to you. It’s completely unlike chatting to a person. Every interaction takes at least a few tens of seconds. And you can’t really interrupt it. This is called steering in Codex, and it’s super useful. You can’t do this with OpenClaw. Slow systems train people not to use them; they’ll prompt and then go do something else. It breaks their flow. One reason ChatGPT got so popular is because it feels like you are chatting to a person. It starts responding right away. A slow AI agent is a lot less fun to talk to. All this is the consequence of OpenClaw just being a huge spaghetti ball of JavaScript that just keeps absorbing more features, more layers, etc. It seems the contributors are mostly amateurs doing whatever without much architectural discipline. At least, that is my read as a backend engineer anyway. Everything about this feels deeply wrong at an architectural and conceptual level. It is a big monolith. It has too much built in that should probably live outside it. Channels are an obvious example. Model configuration and connectors are another one. There is too much tightly coupled product inside one pile, which means every change has more surface area to disturb something else. It’s not surprising it is flaky, slow, and insecure. The Security Story Is Bad If you add all of this up, the security story is not good. In fact, I would go further than that. It is hopelessly insecure in the sense that I do not think this gets fixed with a few patches, a few best practices, or one more round of hardening work. It would need a serious rethink by people who actually understand how to design this kind of system properly. You are talking about a slow-moving monolith with a lot of built-in capability, lots of connectors, lots of channels, lots of moving parts, and a design that already feels wrong before you even get to the security review. That is not where you want to start if you care about enterprise-grade data handling, auditability, or compliance. Could you use it anyway in a smaller context, with limited exposure, to learn things quickly? Sure. Would I want to defend it in front of a responsible CIO, security lead, or compliance team at a large company? Absolutely not. So Why Use OpenClaw At All? Because it got a few important things right. If you want to work with agentic workflows in teams, OpenClaw is or at least was one of the easier systems to get running in a form that feels real. It gives you agents, files, tools, skills, channels, and loops in one place. That makes it easier to see the shape of what multi-agent team workflows can become. Most AI tools are still single-user. But with OpenClaw, connecting it to team chat tools is a thing. Even if it is wonky and less than perfect, it is actually nice to be able to involve multiple people. And of course a lot of real-world workflows in companies involve more than one person. So for an AI to be able to talk to everyone involved is crucial to automating these workflows and reducing people’s workloads. Good news: other tools are available! Developers had a year’s head start getting agentic coding tools that they could delegate a lot of work to. But recently a lot of agentic tools are becoming available that give similar benefits to business users. There is a growing number of SaaS tools you can connect to AI tools. Claude CoWork is great for business users. Codex is catching up fast. Tools like Perplexity Computer and Manus are also going in this direction. These tools are generally easier to use than OpenClaw. They are easier to connect to things. They feel less like you have to become the unpaid maintainer of a confused internal framework just to get value out of them. Of course, the catch is that these tools are still mostly designed for one person at a time. But the good news is that we can emulate a lot of what we did in OpenClaw with Codex automations. And we can even make Codex send messages into Matrix rooms so the team can get daily meeting briefs, industry news summaries, and a lot of the other useful automations we experimented with. You can’t prompt from Matrix unfortunately, so you still have to drop back to single-user mode for a lot of stuff. Enterprise Agentic Tools Are Getting There Too Then there is the enterprise side of the market. If you want something a responsible company can actually use at scale, with a straight face, products from companies like Tines or Langdock are closer to what a serious CIO can justify. They are built for organisations that care about security, compliance, oversight, and controlled deployment rather than just enthusiast energy and feature accumulation. The Hard Problems Are Still Ahead Multiplayer is going to be a game-changer for serious teams. But it will also make a lot of the already quite obvious issues even more painful. For example, giving blanket access to your inbox is already a bit questionable if you do it in a one-on-one chat in Claude CoWork. But how would you do that in a team context? We talk to people who manage several different inboxes for the executives they support. That’s a great use case for agentic AIs. But it’s also a huge security problem. Trust me! I know what I’m doing! The big unsolved problem here is how to deal with security and permissions. There are companies that try to address this, but it’s a very fragmented space, and most SaaS tools either force you into micromanaging permissions (like Slack) or you end up giving blanket access (Gmail). And neither is a good solution. The problem is rather urgent because the tools are getting useful enough that important people are going to insist on using them. And without good solutions this will result in exactly the same type of security issues that pop up every few years in IT. Remember when people were bringing USB keys to the workplace and could introduce viruses and worms to the intranet? Remember Wi-Fi and using your laptop on insecure hotel networks? Email? The pattern is always the same: something new comes along, people start using it, and by the time IT figures out they need to do something, it’s too late. Eventually they figure out how to constrain the new thing without throwing the baby out with the bathwater. We’re about to go through that cycle again with agentic AIs. Wrapping it up We learned a lot using OpenClaw, but of course we cannot recommend it to business users. Forget about using this if you do not have CLI skills. And if your IT department finds out you are using it, they will probably be horrified for very good reasons. But it gave us a way to learn and experiment. It allowed us to fast-forward to a future that the rest of the world can have in a more polished form in a few years. OpenClaw makes multi-agent workflows usable right now. Multiplayer agentic tool usage in teams is a killer feature. Having agents send meeting digests, answer questions from Google Drive, resurrect old sales leads from your inbox, and do many other useful things is gold. And you can do so much more with these tools. We’re only scratching the surface of what is possible. We can now reproduce most of what we found useful in OpenClaw with Codex or Claude Code automations. These tools provide a much more polished experience. We can even push useful outputs into Matrix rooms so our people can get shared meeting briefs, summaries, digests, and other recurring updates. Prompting these tools from there is still a challenge. But it’s a relatively simple one. It will get solved eventually. This is a chaotic space. But if you are a bit brave and adventurous, the future can be now, not in two years. And you don’t have to figure all of this out by yourself. We specialize in coaching teams and executives on getting their feet wet with agentic tools. You can wait a few years for the tools to catch up. Or you can claim back some of your time now. Would you like to jump forward in time a few years? Are you spending too much time in your SaaS tools doing things that clearly can and should be automated? Want to claw back some time? Come talk to us. We can help. We can make this happen right now. We’ll get you started. We’ll help you tackle the first few automations.


Title: What Is Authorship in the Age of AI?
URL: https://formationxyz.com/blog/authorship-in-the-age-of-ai/
Published: 2026-05-21
Author: XYZ by FORMATION
Description: AI did not end authorship. It exposed the difference between pressing generate and actually directing, editing, and taking responsibility for published work.
Body: Generative AI did not end authorship. It exposed weak authorship. If someone asks a model for an article, accepts the first draft, and publishes it unchanged, the authorship claim is thin. The work exists because someone asked for it. That is not the same as making it good, coherent, defensible, or fit for publication. Most authorship and authenticity debates get stuck between two extremes. On one side, the prompter is treated as the author. On the other, the model is treated as the real author. Both miss the more useful question: who actually shaped the work, and who is willing to stand behind it? A prompt is not a serious claim by itself A prompt can be trivial, but it can also be part of serious creative direction. Not all prompts are equal. Treating them as if they were leads to lazy thinking about authorship, rights, and responsibility. This applies to more than writing. It also applies to images, code, music, research summaries, strategy decks, internal tools, and anything else people now create with AI tools. A weak prompt plus passive acceptance can produce output quickly. It does not prove much thought. A stronger AI-assisted process can include original source material, references, constraints, structural decisions, rejected drafts, factual checks, technical review, and final editorial judgment. That starts looking more like authorship because the person is directing the work rather than merely accepting the first usable output. Authorship was never only about typing Even before AI, authorship was not always clean or individual. The classic counter example here is a famous person using a ghostwriter for an autobiography. It obviously involves their story and their life. But writing is a separate craft, and the ghostwriter does the heavy lifting while the public figure takes the credit. Books have editors. Films have directors, writers, actors, producers, and studios. Software has product managers, designers, engineers, reviewers, libraries, and infrastructure. Architecture has clients, engineers, constraints, and revisions. Music has performers, producers, instruments, mixers, and mastering. Good work has always involved direction, coordination, and revision. The person with the strongest authorship claim is often not the person who physically touched every part of the artifact. It is the person who gave the work its shape, standards, and final approval. With AI in the loop, more people can now create with far less help from others. The work just gets compressed into a single tool. That compression hides labor. The model can draft, expand, summarize, refactor, translate, imitate, and vary. The output arrives looking finished, but the production chain behind it is much harder to see and if you are not on top of this, it can easily go wrong. AI tools hide mistakes unless you add guardrails Generic AI chat tools make it easy to generate polished-looking work without much process around it. Weak AI content often starts there. The draft sounds plausible, moves quickly, and hides its own defects. Worse, some models like OpenAI’s ChatGPT have an easy to spot tone to them if you don’t correct them. They are likely to exaggerate, use marketing speak, and lean on em dashes — which are now treated as a tell-tale sign of AI-generated text, much to the dismay of em dash appreciators. Some defects are obvious, but many are subtle and hard to spot. The structure may drift. Claims may overreach. The tone may slip. A quote may be wrong. A legal or factual edge case may survive because nobody built checking into the workflow. Awkward or stunted phrasing can slip through as well. If you are not careful, you end up publishing AI slop. Manual editorial processes have a lot of friction built in. There are drafts, edits, comments, approvals, and visible handoffs. AI compresses that into one interface. This is convenient, but also risky. Guardrails turn content generation into a real process The upsides of using AI are tempting. It can be quick and when it works it can even be great. Nobody wants to manually inspect everything forever. For this to work, we need to automate at least some of the checks we used to do manually. Guarrails is where agentic tools become more useful than plain chat. In systems like Codex, Claude Code, and similar tools, you can define standards around the work instead of relying on memory and discipline every single time. Instead you lay out your process explicitly and based on the results you keep on refining them until the process of content generation becomes repeatable and predictable. Guardrails can cover all the routine checks people care about: language and tone checks against a copy standard factual verification and quote checking approval steps before anything is sent or published source-of-truth checks against the real files, records, or repository translation and localization checks where multiple languages need to stay aligned asset and metadata checks so published outputs point at the right managed files auditability, so the team can see what changed, who approved it, and which checks ran Authorship gets stronger when the person directing the process decides what quality means, what must be checked, what needs approval, and what cannot go out without evidence. The author owns the result In practice, the author or publisher is the person or team that decides the work is good enough to publish and is willing to stake their reputation on it. That does not mean they typed every sentence, drew every pixel, or wrote every line of code by hand. It means they made the decisions that shaped the final result. They checked what needed checking. They rejected what did not work. They accepted the risk of putting it in front of other people. Used well, AI is a bit like having a good editor and an army of interns available all the time. It can draft, summarize, check, suggest, vary, and clean things up. But the editor does not own the book, and the interns do not get final say. Their work still has to be directed, reviewed, corrected, and sometimes ignored. That is also why calling the model a co-author is not very helpful. A model cannot argue for a claim, explain its intent, accept blame, sign off on a final version, or deal with the consequences when the work is wrong. A prompt can start the work. It does not settle authorship. The stronger claim comes from everything that happens after the first output: selection, revision, verification, and final responsibility.


Title: When All Else Is Equal, Ideas Are All That Matters
URL: https://formationxyz.com/blog/when-ai-levels-production-ideas-become-the-advantage/
Published: 2026-05-19
Author: XYZ by FORMATION
Description: AI will make production cheaper, faster, and more widely available. When everyone can build, create, and automate, the scarce advantage shifts to better ideas, sharper taste, and stronger judgment.
Body: AI is starting to level production capacity. That sounds like a statement about technology. It is really a statement about competition. For decades, many ideas died because production was too expensive. A founder could not afford the prototype. A marketing team could not get enough design and development time. An operator could see the workflow problem clearly but could not turn it into software. A small company could imagine a better customer experience and still lack the budget, people, or technical path to build it. AI is starting to weaken that constraint. A person with a clear goal can now generate code, drafts, images, research summaries, workflows, data transforms, sales materials, landing pages, and internal tools at a speed that would have seemed unrealistic a few years ago. The quality still varies. The work still needs review. Real systems still need architecture, security, data discipline, and ownership. The pattern is visible: production is becoming cheaper, faster, and more broadly available. The ironic result is that more technology may make human creativity more valuable. When everybody can produce, production becomes a weaker moat. The advantage moves upstream to the quality of the idea. The old bottleneck was execution Execution used to be the filter. If you wanted a new product, you needed a team. If you wanted a campaign, you needed budget. If you wanted a dashboard, you needed engineering time. If you wanted a useful internal tool, you needed someone who could translate a business process into working software. That filter blocked bad ideas. It also blocked a lot of good ones. The cost of execution meant teams had to ration attempts. They wrote business cases before testing obvious things. They waited for roadmaps. They asked permission from overloaded departments. They merged three small ideas into one larger project because there was only enough budget to build once. This made organizations look more disciplined than they really were. Many were simply constrained. AI changes the shape of that constraint. The first version of an idea can now become visible quickly. A workflow can become a prototype. A pitch can become a deck. A service concept can become a landing page. A messy internal process can become a rough tool that proves whether the problem is real. That is useful. It also exposes a harder question: if execution is no longer the strongest filter, how good are the ideas? The new battleground is better ideas If everybody can create a website, a website is no longer the interesting part. If everybody can generate a deck, the deck is no longer the advantage. If everybody can prototype a tool, the prototype is no longer the scarce asset. The scarce asset becomes the idea behind the artifact. The angle. The insight. The timing. The taste. The understanding of the customer. The ability to see which problem is worth solving and which one only looks urgent because the tool makes it easy to touch. This is where AI becomes uncomfortable for companies that treated production capacity as strategy. A team that won because it could simply make more things may find that making more things is no longer enough. Competitors can make more things too. Smaller teams can now produce outputs that look polished, move quickly, and test the same market faster than before. The gap shifts from “who can make it?” to “who knows what should exist?” That is a more human question. Better ideas come from attention. They come from being close to customers, noticing repeated friction, understanding timing, and having the courage to remove weak concepts early. Better ideas come from taste: the ability to sense when something is useful, clear, humane, and commercially sharp. Better ideas also come from judgment: knowing when to automate, when to simplify, when to add human review, and when a problem does not deserve a system at all. More technology does not remove those skills. It puts more pressure on them. Creativity gets more operational Creativity is often treated as a mysterious front-end activity: the name, the concept, the campaign, the visual, the line. AI makes creativity more operational. A good idea can now move through many forms quickly. It can become a blog post, a sales offer, a prototype, a customer email, a service page, a demo script, a pricing test, a workflow, or a training document. That does not make the original idea less important. It makes the idea easier to interrogate. Does it survive contact with a customer use case? Does it become clearer when expressed as software? Does the landing page make the promise sharper or reveal that the promise is vague? Does the workflow actually save time, or does it only move complexity somewhere else? The creative act becomes less about producing one polished object and more about moving an idea through enough formats to find its strongest shape. This is close to the pattern we described in Getting Good Ideas Unstuck . AI helps ideas move. Human judgment decides whether the movement is useful. The best teams will not use AI only as an output machine. They will use it as an idea-pressure system. Level production does not mean level outcomes The phrase “AI levels the playing field” can be misleading. AI may give more people access to similar production capability. It will not give everyone the same taste, context, urgency, discipline, or courage. Two teams can use the same model and get very different outcomes. One team asks for generic content and ships it because it looks finished. Another team uses the model to test ten angles, reject seven, improve two, and build one with a clearer customer promise. The tool may be the same. The thinking is not. The same pattern applies to software. One company uses AI to generate another dashboard. Another uses AI to remove a painful approval loop, add a simple customer-facing tool, or turn a recurring expert decision into a supervised workflow. Both used technology. Only one improved the business. The leveler gives access. It does not supply the idea. This matters for small companies. Large companies used to have a structural advantage because they could pay for more execution. AI reduces some of that advantage. A small team with strong ideas, fast feedback loops, and clear taste can now look larger than it is. It can test more, ship more, and learn more without building a huge department first. That does not make the small team automatically better. It gives the small team a chance to compete where it may already be strongest: focus, speed, customer closeness, and willingness to rethink the way work gets done. The idea pipeline becomes a company asset If ideas become the battleground, companies need to treat idea development as an operating system, not a workshop. That means capturing friction when it appears. It means turning customer objections into experiments. It means giving operators a way to propose workflow improvements without writing a full business case. It means letting sales, support, delivery, and leadership push raw ideas into a process where they can be tested quickly. AI can help with that process. It can turn a rough note into a sharper problem statement. It can compare several versions of a service promise. It can produce first drafts, prototypes, and simulations. It can help a team explore the consequences of an idea before spending serious money. But the process still needs human standards. Which customer problem is real? Which idea fits the company strategy? Which concept deserves a prototype? Which prototype deserves production hardening? Which output is good enough to test, and which one would damage trust if released? Those are leadership questions, product questions, and operational questions. AI can support them. It should not be allowed to answer them alone. Technology raises the floor and the ceiling The most interesting effect of AI is not that it raises the floor. It does. A weak writer can draft faster. A non-designer can explore layouts. A non-developer can create a prototype. A small business can generate assets, automations, and workflows that once required a larger team. The deeper effect is that it raises the ceiling for people with strong ideas. A good strategist can test more positions. A good operator can turn process knowledge into usable tools. A good founder can explore product directions without waiting months. A good creative team can move from concept to market expression with much less friction. A good domain expert can finally turn tacit knowledge into systems other people can use. AI does not flatten excellence. It amplifies the gap between people who merely produce and people who think clearly. That is the irony. More technology makes human ingenuity more visible. It removes some of the excuses that hid weak ideas behind limited production capacity. It also removes some of the barriers that kept strong ideas trapped inside people who could not execute them. The work ahead The next phase of competition is likely to reward teams that combine fast production with better thinking. They will need tools, but tools will not be enough. They will need idea pipelines, review loops, customer feedback, operating standards, and taste. They will need to know when to use AI for speed and when to slow down for judgment. They will need to decide which ideas deserve automation, which deserve software, which deserve content, and which deserve to be killed. This is where agentic workflows , AI operations layers , and code-centric AI workflows become practical. The goal is not only to make more things. The goal is to make the right things easier to test, improve, and operate. AI will make it easier for everyone to create. That will not make ideas cheap. It will make better ideas matter more.


Title: How We Used AI to Create the Geomob Sponsor Presentation
URL: https://formationxyz.com/blog/ai-generated-geomob-sponsor-doc/
Published: 2026-05-05
Author: XYZ by FORMATION
Description: We used an AI-assisted document workflow to turn sponsor positioning, event context, and review notes into a polished Geomob sponsor presentation PDF without rebuilding the document by hand.
Body: We recently prepared a Geomob sponsor presentation PDF using the same AI-assisted operating model we use for much of our website, sales, and document work. The interesting part is not that AI helped write a document. That is now the easy version of the story. The more useful part is that AI helped us move through the full production workflow: structure, messaging, layout review, editing, export, asset handling, and final publication. Most sponsor documents are still built as manual artifacts. Someone opens a slide or document tool, copies material from earlier versions, rewrites a few sections, adjusts the design, exports a PDF, sends it around, then repeats the same process when feedback arrives. That can work, but it makes every new document feel like a fresh production job. We wanted the Geomob sponsor presentation to move differently. We treated it as a controlled document workflow rather than a one-off file. The document mattered, but the workflow around the document mattered more: structured inputs, review, export, and publication. Starting With The Job Of The Document The first step was not design. It was deciding what the document had to do. A sponsor presentation has a specific job. It has to explain the event context, make the sponsor opportunity easy to understand, show why the audience is relevant, and give a potential sponsor enough confidence to continue the conversation. It should be clear enough to forward, but compact enough to read quickly. AI is useful here because it can hold several layers of context at once. It can compare the sponsor story with the event positioning, check whether the structure answers the reader’s likely questions, and suggest where the document is too vague or too heavy. The human role remains important. We still decide the commercial story, approve the claims, and choose what belongs in the final version. That division of work is practical. AI handles the drafting, restructuring, and consistency checks. People handle judgment, accuracy, taste, and approval. Turning Review Notes Into Changes The biggest time saving came during revision. In a traditional workflow, feedback often turns into a scattered list of small manual edits: tighten this section, make the offer clearer, reduce the amount of text on this page, move this point earlier, make the closing stronger, adjust the tone for a sponsor audience. None of those tasks is difficult by itself. Together, they create drag. With an AI-assisted workflow, review notes can be turned into a coherent edit pass. The system can inspect the whole document, apply the requested changes in context, and keep the rest of the story aligned. That matters because sponsor material depends on flow. A better opening can make a later section redundant. A clearer offer can change what the conclusion needs to say. A stronger audience description can shift the emphasis of the sponsor benefits. This is where document AI becomes more than text generation. It becomes workflow automation for the messy middle of production. Keeping The Output Controlled We do not want AI documents to feel unreviewed, overclaimed, or generic. The control layer is the work. For this document, the useful controls were straightforward: keep the language practical, keep the sponsor value clear, avoid inflated claims, preserve the intended structure, and make the PDF ready to share as a proper asset. Those constraints are similar to the ones we use across the XYZ site. They keep AI output close to the operating need instead of letting it drift into broad marketing language. The asset workflow also matters. Once the PDF was final, we did not drop it into the website repository as a loose file. We uploaded it to the managed asset store under /docs, added sidecar metadata, and verified the public URL. That keeps publishable assets out of Git while still giving the site and the team a stable link to use. The result is the live PDF here: Geomob sponsor presentation . Why This Pattern Matters This small project is a good example of the broader DECK/DOCS pattern we have been building at XYZ. High-quality business documents are rarely just writing tasks. They are usually small production systems. They need inputs, structure, tone, design, review, export, translation in some cases, publishing, and version control. If each step is handled manually, the work becomes expensive fast. If the steps are structured, AI can help move the whole system. That is useful for sponsor decks, sales documents, proposals, event material, investor updates, board packs, onboarding documents, and internal operating guides. The common pattern is the same: define the job, structure the source material, let AI accelerate the document work, keep people in charge of judgment, and publish the finished asset through a controlled path. It also changes how teams think about speed. Faster document production is not only about saving time on one PDF. It means a team can respond faster to opportunities, test better material, reuse strong structures, and keep documents aligned as the offer changes. We used AI to create this sponsor presentation because the old workflow would have spent too much attention on assembly. The better workflow let us spend more attention on the message, the audience, and the final asset. That is the practical value of AI document work. The output is a PDF. The real gain is a repeatable operating model for getting from intent to a useful business document with less drag. If your team still builds sponsor decks, proposals, and sales documents as one-off manual files, our DECK/DOCS workflow is the clearest place to start. For a broader conversation about AI consulting and implementation for document-heavy teams, talk to us .


Title: Your Website Is Not Outdated. Your Website Process Is.
URL: https://formationxyz.com/blog/your-website-is-probably-slower-than-your-business/
Published: 2026-05-04
Author: XYZ by FORMATION
Description: If your website feels hard to keep current, the real problem is usually not design or tooling. It is the process behind updating it.
Body: When was the last time you posted news on your website? Is the FAQ still up to date? What about your product pages? Do they tell the whole story? If the answer to one or more of those questions is no, your website probably needs a serious update. You likely already know that. The bigger problem is usually not the website itself or the technology choice behind it. It is the process behind updating it. Why websites derail You might be using a content management system like WordPress, Drupal, or one of the many online site builders. The process with those tools is still people-driven. Someone has to know where things live, how pages are structured, which shared elements need updating, and how to publish without breaking anything. Those systems also tend to get more brittle over time. WordPress is the familiar example. There is a plugin for everything, until there are too many plugins, too many exceptions, and too many hidden dependencies between them. Team changes make that worse. People leave. New people join. Context disappears. The website still works, but fewer people understand how it works or what should happen when something needs to change. What we’ve seen over and over again with our clients is that they create a new website with the best of intentions and then things drift over time. People leave and new people join. Technical debt builds up in the form of technical or content work that needs attention but isn’t getting any. As this work accumulates, the task just gets larger and larger. Once these tasks escalate into months long projects, the chance that they will ever happen drops further and further. AI to the Rescue? AI has changed what is possible in web development. Website work was one of the earliest practical uses for AI-generated code, and agentic coding tools are already proving they can handle real website tasks. They can update content, adjust templates, clean up metadata, and implement repetitive changes quickly. What is still missing in many small companies is operational adoption by non-technical website owners. Most teams still think in ChatGPT terms: ask for some text, copy it somewhere, and hope for the best. What they need is different. They need a workflow where they can request a website change and have AI work on the website itself, not just describe the change in a chat window. That means AI needs access to the site, the tools around it, and the checks that keep the output reviewable. Agentic AIs address this problem. Making your website agentic Many reasons exist for websites to get in the broken state that we outline. With Agentic AIs, getting out of that mess is something that no longer has to be a lot of manual work. A key point with Agentic AIs vs. the AI tools you might use already (like ChatGPT) is that Agentic AIs help you automate processes. Automating the process of doing updates to your website is something that is fairly straightforward from a technical point of view. Likewise migrating content from one technical solution to another is something that is very doable now. What exactly is an Agentic AI? Before we get into how FORMATION can help, it helps to define what sets Agentic AIs apart from just using ChatGPT. It can work on the real website ChatGPT essentially just gives you text. An agentic workflow can use tools. It can use these to work on the actual website. This includes opening and reading relevant files, creating new ones, updating copy, formatting it correctly, fixing the metadata, adjusting links, and preparing the result for review. All the things you normally do manually by clicking buttons in your CMS are things that an agentic AI can automate. Agents follow strict processes via skills When you use ChatGPT, every conversation starts from zero. It’s Groundhog Day ! Who are you? Who am I? What are we doing? Why am I here? That’s not what you want when you are trying to do real work. For that, you need processes, guardrails, and known ways of getting things done to be implicit. When you work on a website you want to jump straight into the action. To make this possible, you need to define the process. Explain it what right looks like to you. What tools you prefer. What check lists to follow. Your editorial process, approvals, as well as the technical process. Agentic AIs solve this by codifying process as ‘skills’. Some skills you can download will “teach” the AI how to use specific tools. Other skills that you author codify your specific process. They define what you need to happen, and how and when. Skills remove the Groundhog Day effect and turn what is otherwise an unpredictable process into a highly predictable and testable one. Imagine the most diligent process-focused person you’ve ever met sticking to the process no matter what. Exactly as you want it. Computers are good at repeating things once they’ve been told what to do. That’s what you want here. A good set of guard rails can cover everything from: your editorial process language and tone preferences your site structure how to use tools to publish changes automated checks and balances These collective skills become your guard rails. They ensure that the Agent knows what success looks like and that it avoids common failure modes. You can start simple and build these out over time. If you see your agents struggle or go off the rails, more guard rails are the way to get it back on track again. And the good news is that you don’t need to spell it out. A conversation that went off the rails where you had to step in to fix it can become the input to having the AI write down the learnings as a new skill. Skill authoring together with the AI is a process where your guard rails get better over time. As you gain confidence in the system, you’ll be tackling bigger and bigger edits. Doing more complex changes requires planning A real website update usually touches more than one thing. Changing a service page may also require updates to headings, internal links, shared sections, SEO fields, and related landing pages. Agentic workflows defined in skills can handle that full sequence instead of leaving someone to patch the rest by hand. But even if you don’t have the skills fully specified, Agentic tools can learn by example as well. Most Agentic tools use AI models that are capable of reasoning. They go through a little process of gathering information, reading skill files, and making a plan. This is how more complex plans get constructed from the skills and guidelines you’ve provided. It also is able to reason about your existing site. It will inspect it, realize what frameworks and tools you are using and be biased to using that. Without needing to be prompted. Any documentation that is there for developers or your internal people is something that an AI can use as well. It all feeds into the plan. Going from reactive to proactive: recurring processes Some website work should happen regularly. FAQs go stale. News sections get neglected. Metadata drifts. Internal links break. Agentic workflows can help keep that maintenance moving with recurring tasks and review steps instead of letting it sit in a backlog. You can simply ask to have certain processes kick off on a schedule. High-level automations like “Every Wednesday morning, prepare a draft article based on a list of ideas, and notify me for the next step in the editorial process” These high-level, scheduled prompts are where agentic website management comes to life because now you are approving rather than directing, refining rather than authoring, and correcting instead of directing. How we help you get started Many readers are more than capable of figuring this out themselves. If only they had the time. Time is the limiting factor in most small companies, and website process work tends to stay below the line until the backlog becomes too painful to handle. Instead of going through the slow and costly process of piecing together what you need over weeks or months, why not get it done in a few days? What we offer is a fast route to a working agentic website setup. We can clean up your current website, put sensible guard rails in place, and make ongoing updates practical instead of experimental. The scope can stay small or go much further. If you want a full website overhaul, we can do that. If the current design is fine, we leave it alone. If the editing process is already simple in some areas, we do not add complexity for its own sake. The point is to start covering the boxes that are currently being missed and turn them into repeatable work handled by your Agentic Webmaster. We can start small and leave the rest to your team, or keep going once the website workflow is working. Reach out for a free consulting call. Tell us what you want to achieve on your website and we’ll get you started.


Title: Should We All Now Build Our Own Internal Tools with AI?
URL: https://formationxyz.com/blog/build-your-own-internal-ai-tools/
Published: 2026-04-30
Author: XYZ by FORMATION
Description: AI makes custom internal software much easier to produce. The harder question is still what to build, what to buy, and how to avoid ending up with a stack of half-supported internal tools.
Body: For most of software history, companies had to make a basic choice. Buy software off the shelf, or build something yourself. In practice, that decision was often less open than it sounded. Building custom software used to be such a labor-intensive, slow, and expensive investment that many companies barely treated it as a real option. Unless the workflow was strategically critical, unusually large, or impossible to support with standard software, the default answer was usually to buy. Buying usually meant faster setup, lower upfront risk, and fewer engineering decisions. Building usually meant more flexibility, but also more cost, more maintenance, and more ways to get things wrong. AI changes that equation. It is now much easier for a company to build narrow internal software for its own use. A team can create a workflow tool, a quoting assistant, a reporting layer, a meeting-prep tool, a document pipeline, or a lightweight operations dashboard much faster than before. That software does not need a pricing page, a sales motion, a customer success team, or a polished market narrative. It only needs to work for the internal team using it. That is a real shift. It lowers the threshold for custom internal tooling so dramatically that building is no longer a rare edge-case decision. In some teams, it will now be the first instinct. That is exactly why the old buy-versus-build debate needs to be revisited. But the easy part is not the important part. The hard part is still knowing what to build, how to structure it, where it should connect, how much control it needs, and who is responsible when it starts to break. The buy-versus-build question now sits much closer to everyday internal workflows because AI has lowered the cost of creating custom software. AI makes custom tooling cheap. It does not make it good. The new temptation is obvious. If a team can generate a workable internal app in a day, why keep bending the business around generic software that only partly fits? Why live with awkward CRM workflows, clumsy reporting exports, scattered meeting notes, or repetitive manual handoffs if a custom tool can close the gap? In many cases, that instinct is right. There are plenty of workflows where buying a large platform is excessive and waiting for a vendor roadmap makes little sense. A small custom tool can be the right answer when the workflow is specific, repeated, and closely tied to how the business actually operates. The problem is that AI makes software generation feel like software completion. A team gets a working interface. The core prompt behaves well enough in a demo. A few integrations are wired together. The result feels useful, so the organization quietly starts depending on it. That is where the trouble starts. The tool may still have weak permissions. The edge cases may not be handled. The workflow may rely on one person who understands the prompts. Logging may be thin. Failure modes may be invisible. The data model may have no sensible route to version two. The tool may solve one pain while creating three new maintenance obligations around it. Cheap production is not the same thing as good engineering. This is the same judgment problem we described in Everybody is a developer now. What happens next? . AI lowers the cost of generating software artifacts. It does not automatically improve architecture, operational discipline, or ownership. The real risk is internal tool sprawl The obvious fear used to be that companies would build too little because custom software was expensive. The new fear should be that companies build too much because custom software feels almost free. One team builds a lead-routing helper. Another builds a customer-summary assistant. Someone in operations builds a scheduling layer. Marketing builds a content workflow. Finance experiments with invoice extraction. Soon the company has a growing stack of internal tools, small automations, prompts, connectors, and agentic workflows that nobody sees as one system. Each tool may be useful on its own. Together, they can become a mess. The organization ends up with half-documented workflows, unclear ownership, duplicated logic, inconsistent permissions, scattered data handling, and tools that work just well enough to keep running while quietly becoming operational dependencies. That is the turbocharged version of the old problem. AI lets a team dig a much deeper hole much faster. It can create internal tooling leverage, but it can also create a whole estate of half-working software that nobody fully owns and everybody is nervous to touch. This is one reason we keep pushing code-centric AI workflows and closed-loop systems . If internal tooling is going to multiply, it needs structure, reviewability, and controlled feedback loops around it. Internal tools still need product thinking A common mistake is to treat internal software as if it does not need proper product thinking because it is “just for us.” That is backwards. Internal software usually sits closer to the actual operations of the business than public-facing software does. It touches approvals, records, documents, scheduling, customer handling, reporting, and recurring execution. If an internal tool is confusing, unreliable, or badly permissioned, the damage lands directly inside the company. The fact that it is not sold externally does not make it low stakes. Good internal tools still need: a clear workflow owner a defined job to be done clear inputs and outputs human approvals where risk exists sensible permissions support and maintenance responsibility a plan for edge cases, logging, and failure Without those basics, the company is not building capability. It is building fresh operational debt. The buy-versus-build question has changed shape The old version of the question was mostly about software economics. Is it worth paying engineers to build something custom when a vendor product already exists? The new version is more operational. Is this workflow important enough, specific enough, and stable enough to justify internal ownership? That leads to a more useful split. Build when the workflow is close to your real operating advantage, crosses too many awkward tool boundaries, or needs a very specific combination of automation, judgment, and internal context. Buy when the workflow is commodity infrastructure, heavily standardized, or better handled by a mature product with established support, compliance, and maintenance. Many companies will do both at once. They will buy the large system of record and build narrow layers around it. They will keep core platforms for CRM, accounting, documents, or support, but add internal AI tooling where the business needs better orchestration, better retrieval, faster drafts, or cleaner operational follow-through. That hybrid model is likely to become normal. The mistake is not building. The mistake is building without a model for ownership. Someone still has to support what gets built This may be the least glamorous part of the whole conversation, but it matters the most. Every internal tool becomes someone else’s future problem if no owner is named. Prompts drift. APIs change. business rules evolve. Teams change. Data sources get renamed. A workflow that seemed obvious in April stops making sense in October. A tool that saved time for one quarter becomes confusing six months later because nobody maintained the assumptions it was built on. That means the AI era may create a more common internal role that many smaller teams have not had before. Not necessarily a full software department. Not necessarily a classic IT role. But a practical internal tooling owner, or a small tooling function, responsible for keeping the organization’s custom software, automations, and agentic workflows usable over time. Large enterprises already have internal platform teams, workflow teams, and tooling specialists. Smaller companies may increasingly need lighter versions of the same idea. If custom software becomes cheap enough, support responsibility becomes the real scarcity. Guardrails matter more, not less This is where AI has created a strange illusion. Because building is easier, some teams assume less discipline is needed. The opposite is true. If a team can spin up internal tools quickly, it needs stronger guardrails around what gets built, what data can be touched, which workflows need approval, who can ship changes, and how failures are surfaced. Faster production raises the value of governance because the volume of possible mistakes goes up with it. That does not require heavy bureaucracy. It does require operating standards. Before a team builds ten internal AI tools, it should have a view on questions like: Which workflows are safe to automate? Which ones need human approval? Which tools can touch customer or employee data? Where should logs and outputs live? Who reviews a workflow before it becomes a dependency? Who fixes it when it breaks? This is exactly where a Company-Wide Agentic Workflow , tighter agentic coding workflows , or a stronger security review can be more useful than another shiny AI demo. The hard part is not finding one more way to generate software. The hard part is creating an environment where useful tools stay useful. What this may lead to The positive version is clear. Smaller companies can finally justify custom internal tooling that used to be out of reach. Teams can remove repetitive manual work, support better decisions, and create software that fits the way they actually operate instead of forcing themselves into generic workflows. The negative version is also clear. Some companies will fill themselves with brittle internal apps, disconnected agentic workflows, and under-supported tools that nobody wants to own. So the question is no longer only whether you should buy software or build it yourself. The better question is whether your team can build internal tools with enough judgment, structure, and support discipline to keep them from turning into a second layer of operational chaos. AI has made custom internal software dramatically easier to produce. It has not made it self-maintaining, self-governing, or self-justifying. That is why the next serious advantage will not come from building the most internal tools. It will come from building the right ones, with clear ownership, good controls, and a plan to support them after the first demo. If your team could build almost any internal tool this year, which ones should still be bought, which ones should be built, and who should own the software you create for yourselves?


Title: The AI Adoption Dilemmas Facing Small Businesses
URL: https://formationxyz.com/blog/small-business-ai-adoption-dilemmas/
Published: 2026-04-29
Author: XYZ by FORMATION
Description: Small companies know they need to work with AI, agents, and workflow automation. The hard part is choosing where to start without creating hidden operational, privacy, and reliability problems.
Body: Small businesses are entering the AI adoption phase that websites went through in the 2000s. Back then, many companies knew they needed a website before they fully understood what the site should do. Some needed lead generation. Some needed credibility. Some needed customer support. Some needed a digital brochure because everyone else suddenly had one. The pressure was real, even when the strategy was unclear. AI now creates a similar pressure, but the operating risk is much higher. A website could be badly written, slow, or hard to update and still remain mostly separate from the core business. AI adoption reaches into the way a company handles customers, documents, decisions, privacy, knowledge, internal coordination, and daily execution. The website rush is a useful comparison, but AI adoption reaches much further into how a company actually works. That makes the question harder for small companies. They can see that something is changing. They can see competitors experimenting with AI agents, AI workflow automation, AI-assisted sales, automated reporting, and faster content production. They also know they do not have the budget, time, or internal technical team to turn every promising idea into a controlled production system. The dilemma is no longer whether AI is relevant. The dilemma is how to adopt it without making the company more fragile. The first problem is choosing where to start Most small companies have dozens of possible AI use cases. Customer service could use better triage. Sales could use cleaner follow-up. Finance could use document extraction and reconciliation. Operations could use scheduling support. Leadership could use better briefs. Marketing could use a more consistent content and SEO workflow. Admin could use help with forms, supplier communication, procurement, and insurance paperwork. The list grows quickly because the work is everywhere. That creates a prioritization problem. A small business usually cannot redesign every process at once. If it starts with the flashiest AI demo, it may waste time on something that looks impressive but changes little. If it starts with the most painful workflow, it may run into messy data, unclear ownership, or compliance questions before the team has learned how to work with AI safely. A useful starting point is the workflow where three things overlap: repeated manual effort, clear business value, and manageable risk. Lead qualification, meeting preparation, document summaries, internal knowledge retrieval, weekly status briefs, proposal drafting, and routine follow-up often fit that pattern. They are close enough to real work to matter, but they can be designed with human approvals before anything becomes binding. This is where process mapping matters more than enthusiasm. Before a company buys another AI tool, it needs to understand where the work actually moves, who owns each step, which data is involved, what can be automated, and where human judgment must stay in the loop. The second problem is weak processes becoming automated processes AI makes bad processes faster. If a company already has unclear handoffs, inconsistent naming, scattered documents, weak CRM hygiene, or no shared view of customer status, AI will not automatically fix that. It may copy the confusion into a faster system. The company can end up with quicker drafts, quicker summaries, quicker routing, and quicker mistakes. Small companies are especially exposed because much of their operating knowledge lives in people’s heads. A founder knows which customer needs special handling. One project manager knows which supplier is unreliable. One administrator knows which documents are usually missing. Those details may never have been formalized because the team was small enough to cope informally. Agentic workflows change that. Once a workflow starts taking actions, preparing outputs, routing tasks, or updating records, the informal knowledge needs to become explicit enough for the system to use and for the team to review. That does not mean every small business needs enterprise process architecture. It means the company needs enough structure for the workflow it is automating. Inputs need to be clear. Outputs need to be reviewable. Escalation paths need to exist. Ownership needs to be named. When the AI cannot tell whether a case is normal, it should know who to ask. The third problem is tool sprawl Small companies often adopt software one pain point at a time. One tool for CRM. One for email campaigns. One for accounting. One for documents. One for project work. One for chat. One for analytics. AI can make this pattern worse. Every team member can now find a clever AI assistant for their own corner of the business. That looks productive at first. Sales gets a tool. Marketing gets a tool. Operations gets a tool. The founder gets a tool. Soon the company has several systems drafting, storing, summarizing, and moving sensitive information with little shared oversight. The hidden cost is operational fragmentation. Nobody has a full view of which tools hold which data, which prompts are being used, which outputs affect customers, or which automations are quietly shaping decisions. Tool sprawl also makes GDPR, security, access management, and vendor review harder because the plumbing is distributed across services that were never designed as one operating layer. For AI implementation, the architecture question arrives earlier than many small companies expect. The answer is not always a large platform. Sometimes a narrow tool is enough. But someone still needs to decide what belongs in the shared operating layer, what can remain an individual productivity tool, and what should not touch customer or employee data at all. The fourth problem is privacy and legal exposure Data protection becomes more complicated when AI is embedded in normal work. It is one thing to ask a public chatbot to rewrite harmless marketing copy. It is another to feed customer records, employee notes, contracts, invoices, support conversations, health details, payment information, or confidential partner material into a workflow that calls external models, stores intermediate outputs, and sends results between tools. For companies operating under GDPR, the questions become practical very quickly: What personal data is being processed? Which provider receives it? Where is it stored? How long is it retained? Can the company explain the purpose of the processing? Can access be limited to the right people? Is there a human approval step before sensitive output is used? Can the company reconstruct what happened if something goes wrong? The difficult part is that AI plumbing can be hidden. A workflow might look like a simple button in a CRM, a Slack command, a document assistant, or a browser extension. Behind that button, data may move through prompts, logs, embeddings, third-party APIs, file stores, analytics systems, and notification tools. Small businesses do not need to become legal departments. They do need a basic control model before AI touches sensitive operations. That model should cover permissions, logging, retention, vendor choices, review points, and the categories of information that should never enter a given system. The fifth problem is trust without auditability AI output often feels usable before it is dependable. That is dangerous in business workflows. A summary can sound right while omitting the one clause that matters. A sales follow-up can sound polished while promising something the company cannot deliver. A financial extraction can look tidy while misreading a number. A support triage can classify a customer issue as routine when it should be escalated. The solution is not distrust by default. It is reviewable AI. Reviewable AI workflows leave traces. They show the source material. They keep drafts separate from approved outputs. They log actions. They make it clear when a human approved something. They route uncertain cases to the right person. They make failure visible early instead of hiding it behind fluent language. For small businesses, this matters because a single mistake can carry more weight. One bad customer message, one privacy breach, one wrong invoice workflow, or one broken handoff can consume the time that automation was meant to save. Human-in-the-loop workflows are not a sign that AI adoption is timid. They are the practical route to trusted AI autonomy. The sixth problem is skills inside the company AI adoption is a technology project and an operating-skills project. It changes what people need to understand about their own work. Someone has to write better instructions. Someone has to judge outputs. Someone has to spot when a workflow is hallucinating, overreaching, or using the wrong context. Someone has to decide whether a task is safe to automate. Someone has to maintain the prompts, data sources, permissions, and feedback loops after the first version goes live. In a small business, those responsibilities usually land on people who already have full jobs. This creates a skills dilemma. The company needs enough AI literacy to use the new systems well, but it may not need a full AI team. It needs practical internal owners: the person responsible for sales follow-up, the person responsible for operations, the person responsible for finance, the person responsible for customer support. Each owner needs to understand what the AI is allowed to do, when to intervene, and how to improve the workflow over time. AI consulting and implementation should therefore include enablement. The goal is not to leave the company dependent on a black box. The goal is to give the team enough operating confidence to use, review, and improve the system. The seventh problem is measuring value Many small companies struggle to tell whether AI is working. Time saved is useful, but it can be vague. Better measurement comes from specific workflow outcomes: faster lead response, fewer missed follow-ups, shorter proposal turnaround, fewer manual re-entry steps, cleaner meeting actions, quicker document review, reduced backlog, better internal search, or fewer status meetings. The value of AI should be tied to a workflow that already matters. If an AI system reduces ten minutes of manual work once a month, it may be interesting but not important. If it removes thirty small coordination tasks every week, improves response time, and gives the founder back attention, it can change how the business feels to run. Small companies should avoid chasing AI for its own sake. The better question is where operational automation removes enough friction to affect revenue, service quality, owner time, or delivery reliability. A practical path for small businesses The best AI adoption path usually starts smaller than the ambition. Pick one workflow that matters. Map it. Identify the data involved. Decide what the AI can draft, summarize, route, retrieve, or check. Add human approvals where risk exists. Keep the first version narrow enough to inspect. Measure whether it actually reduces work or improves quality. Then expand from a controlled base. That is the difference between experimentation and implementation. Experiments are useful when the team is learning. Implementation begins when a workflow has an owner, a control model, a review process, and a reason to keep running every week. This is the work XYZ by FORMATION is built around. A Company-Wide Agentic Workflow helps a team map the operating system before automating it. OpenClaw Setup gives small teams a more capable AI operations layer for recurring work. NemoClaw Setup is useful where privacy, security, and permissions need stronger guardrails from day one. More focused services such as Sales Follow-Up Operator , Exec Briefing Agent , and Meeting Prep and Decision Pack help teams start with one clear operating pain. Small businesses do need to get onto this new wave. The companies that wait too long will feel more pressure as competitors, suppliers, and customers start operating at AI-assisted speed. The companies that move well will not be the ones that install the most tools. They will be the ones that turn AI into controlled operating capacity: useful workflows, clear ownership, human approvals, good records, privacy discipline, and steady iteration. That is a more complicated shift than getting a website was. It is also a larger opportunity. AI can give small companies capabilities they could not previously afford, but only if they treat adoption as operational design rather than software shopping.


Title: How to Fix a Failing AI Workflow
URL: https://formationxyz.com/blog/frustration-inversion/
Published: 2026-04-28
Author: XYZ by FORMATION
Description: If an AI workflow keeps failing in the same way, the fix is usually better workflow design: clearer task boundaries, stronger guard rails, and earlier review steps.
Body: Most teams using AI in operations hit the same problem sooner or later. A task looks simple. The system gets close, then fails in a familiar way. You try again. You add a sentence. You correct the output manually. The next run misses in roughly the same place. That loop is frustrating. It is also useful. Repeated frustration usually means the AI workflow is telling you something. The task may still be too vague. The model may have too much freedom. The review step may come too late. The system may not have enough context to succeed reliably. Frustration inversion means treating that pattern as workflow design feedback instead of treating each bad run as a one-off irritation. When AI Workflow Failure Becomes Signal One weak result does not tell you much. AI systems still have variance. A single bad answer may be random noise, weak source material, or a bad pass. The signal appears when the failure repeats. If a model keeps writing in the wrong tone, the issue may be missing editorial rules. If it keeps overreaching on research, the issue may be weak source constraints. If it keeps damaging the same part of a codebase, the issue may be weak task decomposition, missing tests, or poor repo grounding. If it keeps making bad judgment calls, the issue may be that the task should advise rather than act. At that point the frustration is evidence. You already paid for it. The useful move is to extract the lesson. What Repeated AI Workflow Failure Usually Means Most recurring AI failures point to one of a few structural problems. The task was underspecified. The system had too much freedom where tighter rules were needed. The context package was missing something important. The review step happened after too much damage was already possible. The workflow asked the model to make a call it was not well positioned to make. Teams often react by adding more prompt text. Sometimes that helps. Often it does not. A longer instruction is not the same as a better workflow. If an agent keeps choosing the wrong files, give it a narrower file boundary or a verification step before edits. If a content workflow keeps producing inflated copy, ban the patterns you do not want and encode the tone you do want. If a research workflow keeps mixing strong evidence with weak claims, require explicit sourcing and confidence language. If a support workflow keeps escalating too late, move the escalation threshold earlier. These are workflow design changes. They usually matter more than one more irritated retry. Add Guard Rails Before The Next Run After a failed run, most teams ask, “How do I fix this output?” A better question is, “What instruction, guard rail, checklist, eval, or handoff should have existed before this run started?” That shift moves the work from cleanup to design. One manual correction fixes one result. One good rule can prevent a whole category of bad results from recurring. One review gate can stop a weak workflow from causing visible damage. One tighter task boundary can turn a messy job into a reliable one. This is how AI work becomes operational. The team stops reacting to every bad run emotionally and starts using recurring failure as input for system improvement. A Practical Example Take a team using AI to prepare client-ready proposals. The drafts come back quickly, but they keep overpromising delivery speed, using generic claims, and missing commercial caveats that the sales lead always adds by hand. The wrong response is to keep correcting those documents manually forever. The better response is to redesign the workflow: add approved positioning language add banned phrases and unsupported claim rules require a section for delivery assumptions and dependencies force the model to separate confirmed scope from inferred scope add a final human approval step before anything client-facing leaves the system Now the frustration changed the operating model. That is the useful outcome. The same logic works in engineering, research, operations, and support. If the same failure keeps appearing, the job is no longer to complain about it. The job is to contain it. Prompt Fix Or Workflow Redesign One of the most important judgment calls in AI work is deciding whether a problem belongs in the prompt or in the workflow. If the failure is small and local, the fix may belong in the prompt. A missing output format, a missing audience definition, or an omitted constraint can often be corrected directly. If the failure keeps returning across runs, people, or models, it usually belongs in the workflow. That might mean a reusable skill, a checklist, a better system prompt, a more structured input format, a narrower tool boundary, or an approval gate. Many teams stay trapped in local prompt repair long after the real problem became structural. That is one reason code-centric workflows are useful in AI operations. When instructions, assets, validation, and review steps live in files and scripts, the next run can benefit from the last failure. Do Not Turn Every Friction Point Into Bureaucracy Not every bad run deserves a new policy. Some failures are random. Some are cheap to fix. Some happen so rarely that a heavy control would cost more than the mistake. The goal is not to surround every workflow with needless rules. The goal is to identify repeatable, expensive, or risky failure modes and address them at the right level. Teams need to ask: Does this happen often enough to matter? Is the cost of repetition higher than the cost of a new rule? Should the system be constrained more tightly, or should the task be decomposed differently? Does this step need review, or should the model stop making this call altogether? Good AI operations depend on that pruning. A system buried under pointless constraints becomes slow and brittle. A system with no AI guard rails wastes time in a different way. The Habit That Compounds When frustration shows up, pause before you retry. Look for the pattern. Name it. Decide whether the issue lives in task framing, context, workflow structure, permissions, or review. Then make a change that improves the next run, not only the current one. Teams that keep extracting rules from repeated failure get calmer, faster, and more reliable over time. Teams that keep repairing the same output by hand stay busy without getting much better. Frustration is normal in AI work. Repeating the same frustration indefinitely is optional. If your team is using AI across content, engineering, research, or internal operations and still spending too much time on avoidable retries, contact us . We help teams turn loose AI usage into workflows with clearer constraints, better handoffs, and less repeated friction.


Title: Why Your Business Needs an AI Ops Layer Now
URL: https://formationxyz.com/blog/why-small-businesses-need-an-ai-operations-layer/
Published: 2026-04-23
Author: XYZ by FORMATION
Description: Many businesses are spending more and more extra time just to keep up. The volume and speed of business communication now outruns human-only operations.
Body: A lot of businesses are under growing communication pressure, and small businesses often feel it first. That does not always mean they are visibly failing or standing still. In many cases, people are keeping things together by working extra hours around the edges of the day. Messages arrive across email, chat, meetings, docs, decks, project tools, CRMs, procurement threads, customer requests, and internal follow-ups. Every meeting creates more admin. Every decision creates more documentation. Every customer conversation creates more tracking work. For a lot of people, the visible job is only part of the real job. The hidden job is stitching together the moving information around it. That hidden job has expanded and dramatically increased in speed, and many teams are absorbing it with unpaid overtime, fragmented attention, and constant follow-up work rather than with a better operating layer. One conversation from the weekend made the point clearly. Someone running government projects inside a consultancy described a routine of working two extra hours in the morning and two extra hours in the evening just to review and answer email. The main working day was full of meetings and calls that generated follow-up work faster than it could be cleared. That pattern is not unusual anymore. It is a sign that the operating model is breaking down. For many people, the real workload is now their formal job plus an extra fifty percent of information handling, triage, and follow-through. The problem is no longer only headcount Lean businesses, especially small businesses, have always been stretched. That part is not new. What changed is the speed of electronic communication and the amount of coordination work wrapped around ordinary business activity. A lean company may still have the same number of people it had before, but each person is now exposed to more channels, more documents, more parallel threads, more status updates, and more required responses than the old operating model assumed. This creates a bad loop. The more overloaded people become, the more they rely on hurried meetings, partial notes, vague ownership, and reactive communication. That creates even more follow-up work. The company starts to feel chaotic even when the people are trying hard. This is one reason The End of Notifications matters. Most companies are still running on interruption-first systems while the volume of inputs keeps rising. That is a poor fit for human attention and a poor fit for operational reliability. Human-only operations are becoming less viable There is a useful comparison in financial markets. Automated trading long ago reached a speed where no unaided human could realistically stay in the loop for every small move. The human role shifted upward toward oversight, strategy, boundaries, and exception handling. Most businesses are not the stock market. The point is the operating shape. Business communication is accelerating. It is still human to human in many places, but it is increasingly mediated by software, templates, AI drafting, automated outreach, and much faster response cycles. That means the practical speed of business is rising even when the team size is not. If one side is AI-augmented and the other side is manually processing everything, the slower side starts to drown in coordination work. This is going to hit administrative work first and hardest. Project coordination, sales follow-up, reporting, scheduling, compliance prep, customer handoffs, proposal work, and document-heavy operations all become harder when the communication layer speeds up faster than the team’s ability to absorb it. That is why I think there is an emerging job crisis in some white-collar functions. The crisis is not only job loss. It is that the unaided version of the job is becoming progressively harder to perform well. More people will find that their normal working day is no longer enough to keep the system under control. There is an old line from The Matrix that still fits: “Never send a human to do a machine’s job.” That lands because a lot of modern office work has drifted toward exactly that mistake. People spend large parts of the day moving data from one system to another, copying status from one document into another, pulling points out of inboxes into trackers, or manually stitching together updates that software should already be carrying. That is a poor use of human time. Humans are better used for judgment, empathy, persuasion, escalation, taste, and decision-making. Computers are better used for repetitive transfer, sorting, matching, logging, and structured follow-through. A short reference point for the argument here: humans should not be used as manual data movers when a machine can carry the repetitive load better. What an AI operations layer actually does An AI operations layer is not one chatbot sitting next to the team. It is a working layer across the company that can read, sort, summarize, route, draft, remind, reconcile, and track. It can turn an inbox into a ranked work queue. It can turn meeting notes into decisions and follow-ups. It can flag missing documents before they become blockers. It can condense scattered updates into a useful daily or weekly brief. It can keep moving records in sync across systems instead of relying on someone to remember the next manual step. This is where AI workflow automation becomes practical for normal operating teams, and especially useful for small businesses that do not have spare administrative capacity. The point is not to make everything autonomous. The point is to remove the dead weight of routine coordination work so humans can spend more of their time on judgment, customers, delivery, and problem-solving. A useful AI operations layer should help with work such as: inbox triage and response drafting meeting synthesis and follow-up routing document extraction and structured summaries sales pipeline tracking and post-call actions recurring status briefs for leaders and operators cross-system admin work that currently lives in someone’s head That is the real opportunity in AI consulting in Berlin and similar markets. Many businesses do not need another abstract AI strategy deck. They need workflow automation that reduces the pile of half-done work, missing context, and exhausting follow-up loops inside the company. Chaos is expensive even when nobody notices it Poor organization does not only look messy. It changes the economics of the company. You get senior people doing clerical cleanup. You get customer replies delayed because the facts are spread across six tools. You get meetings that exist only because nobody trusts the record from the last meeting. You get part-time workarounds instead of real fixes because the business cannot yet afford the full-time people who could clean up the system properly. That creates a company that is always catching up. A lot of businesses now live in that state. Small businesses often feel it most sharply because there are fewer buffers, fewer specialist roles, and less slack in the system. Things are half done. People are half allocated. Ownership is fuzzy. The team keeps moving, but much of the movement is compensating for operational drag rather than creating progress. An AI operations layer helps most when it reduces that drag before the company hires more people into a bad system. Businesses need leverage, not more noise This is why we see AI-powered operations consulting as such a large opportunity. There is a lot of chaos in the market. Many teams are running hard just to maintain visibility across their own work. The winners will not be the companies that bolt a few AI features onto the side and call it transformation. They will be the companies that redesign the operating layer around the actual bottlenecks: communication load, fragmented information, slow follow-up, and missing structure. That can mean Claude Cowork Setup for research and document-heavy work. It can mean Sales Follow-Up Operator for post-call execution. It can mean Exec Briefing Agent or Meeting Prep and Decision Pack for leadership information flow. It can mean a deeper Company-Wide Agentic Workflow when the whole company needs a better operating model. The common thread is simple. Businesses need enough AI implementation discipline to keep up with the pace of modern business without burning people out in the process. For small businesses, that need is often more urgent because the same person is usually carrying delivery, communication, coordination, and administrative cleanup at once. If your team feels like it is always a week behind its own inbox, its own meetings, and its own internal follow-up work, the problem may not be effort. The problem may be that the company now needs an AI operations layer and still does not have one.


Title: Everybody is a developer now. What happens next?
URL: https://formationxyz.com/blog/everybody-is-a-developer-now/
Published: 2026-04-21
Author: XYZ by FORMATION
Description: AI-native software development is getting easier fast. The hard part is no longer generating an app or website. The hard part is judgment: architecture, security, UX, data, and operational control.
Body: Software generation just became much cheaper. That changes more than the developer job market. It changes who gets to build. A founder can open Codex, Claude, Cursor, Lovable, Bolt, Replit, or the next code generator and get a working interface quickly. A marketer can spin up a campaign microsite. An operator can automate an internal workflow. A product manager can mock up a dashboard that would have needed engineering time a year ago. That is real progress. It is also where many people stop thinking. The ability to produce software is spreading faster than the ability to judge software. Those are not the same skill. You can generate a UI without knowing whether the underlying state model is brittle. You can scaffold a backend without knowing whether the data model will survive version two. You can store media somewhere that works for a week and becomes painful after the first real spike in usage. You can add authentication without understanding session handling, roles, or the attack surface you just opened. The same problem shows up in product quality. A generated interface may look polished and still be confusing. A flow may work in the happy path and break the moment a real customer behaves like a real customer. A product can look finished on demo day and still be structurally messy, expensive to maintain, and unsafe to extend. This is why “everyone is a developer now” is true and misleading at the same time. More people can now generate software artifacts. Fewer people can reliably decide whether those artifacts are well designed, secure, maintainable, and worth building further. Cheap production changes the bottleneck For a long time, software production was constrained by scarcity. Not enough developers. Not enough time. Not enough budget to test ten ideas and throw eight away. That constraint is weakening fast. The new bottleneck is judgment. Which ideas deserve implementation. Which architecture can support the next step. Which workflows need speed and which ones need stronger controls. Which parts should remain simple and which parts need deliberate engineering discipline early. This is close to the pattern we described in Hyper Agile and What if time to market was measured in hours or days instead of months or years? . The path from idea to software output keeps shrinking. That is useful. It also means teams can now create expensive mistakes much faster than before. Bad architecture used to take time to accumulate. Now a small team can generate a surprising amount of technical debt over a weekend. That is not an argument against AI-native software development. It is an argument for taking the operating layer more seriously. The new risk is fast, confident wrongness The danger is not only broken code. The danger is confident progress in the wrong direction. A founder ships a prototype that works and assumes the backend shape is good enough to scale. A sales team launches an internal tool with weak permissions and no serious review of how customer data is handled. A marketing team generates a landing page fleet that looks coherent but quietly damages SEO, accessibility, analytics quality, or brand consistency. A team automates a recurring process without noticing that the workflow has no proper fallback, logging, or approval gate when the system starts behaving oddly. These are not edge cases. They are the natural consequence of putting high-output tools in the hands of people whose discernment is still catching up. We are moving into a world where more people can act like developers before they know how to think like developers. Even that is too narrow. Product judgment, security judgment, UX judgment, and operational judgment matter just as much. One recent example from our own work makes the point neatly. We built a small sales tool that takes core deal metadata and turns it into polished sales offers and matching sales decks. The same offer can switch between English and German quickly. The deck can be styled against the customer’s corporate identity. The output is fast, useful, and presentable. The problem was everything around that happy path. The security model was weak. The hosting setup was not properly thought through. The route to a production-ready server setup was not obvious to a non-developer. Media was stored inefficiently. The tool was good enough to prove the concept and rough in exactly the places that become expensive later. That is the pattern. AI implementation is making it easier to get to “it works.” It is not automatically teaching people how to make the thing robust, secure, maintainable, and operationally sane. A generated app is not the same thing as a good product The surface layer is getting easier first. That means the market is filling up with generated interfaces, quick prototypes, half-operational internal apps, and convincing frontends. Some of them will be useful. Many will be shallow. Good UX still requires taste. Good system design still requires tradeoff decisions. Good security still requires paranoia, not just a library install. Good operations still require monitoring, rollback paths, and clear ownership. Good data design still requires thinking about what changes later, not only what works right now. This is one reason code-centric AI workflows matter so much. Structured files, scripts, repos, validation, and reviewable environments make it easier to inspect what the system is really doing. The issue is not that non-developers are touching software. The issue is whether the workflow gives them enough structure to avoid quietly stepping on landmines. That same logic applies to websites, internal tools, product prototypes, and operational automation. The UI can now arrive early. The need for discipline did not disappear with it. What happens next Three things are likely to happen at once. First, a lot more people will build software and ship useful things without formal engineering backgrounds. That is good news. More ideas will get tested. More teams will stop waiting for permission. More business workflows will move into software because the production cost has dropped far enough. Second, a lot of teams will dig themselves into holes faster than before. They will accumulate technical debt, weak data handling, brittle workflows, vague ownership, and bad user experience under a layer of impressive velocity. Third, the tools themselves will get better at steering users away from costly mistakes. Some of that will come from stronger models. Much of it will come from better harnesses, evals, templates, permissions, and guided workflows around the model. The deeper opportunity is not only to help more people write code. It is to help more people operate software work safely. That means checklists. It means starter architectures. It means opinionated defaults. It means review gates. It means better prompts, but also better systems around prompting. It means giving a non-engineer a way to build something useful without also giving them easy access to hidden failure modes. Agentic coding tools are going to need more architectural guidance as part of how they work. Faster generation on its own is not enough. The useful systems will increasingly tell people where to host, how to think about media storage, when security review is needed, which defaults are risky, and where a prototype should stop pretending to be production. The real product is guided capability This is where the next wave will separate itself from the current wave of vibe-coded demos. The winner will not be the tool that merely helps a user ship something flashy in twenty minutes. The winner will be the workflow that helps a user ship something useful without making avoidable mistakes in architecture, security, UX, or operations. That matters inside companies as much as in consumer tools. If everybody now has some developer capability, then companies need a stronger operating model for how that capability gets used. Who reviews what. Which systems can be touched. Which tasks need approval. Which patterns are safe to reuse. Which workflows need QA testing , security review , or tighter agentic coding workflows before they become real dependencies. This is also why we keep pushing supervised AI workflows , closed loops , and skill trees for AI users . Cheap capability without skill is unstable. Cheap capability with guard rails becomes leverage. Everybody is not becoming a great developer. Everybody is getting access to more developer-like power. That is enough to change how websites, apps, automations, and internal systems get built. It is also enough to create a lot of avoidable damage if teams confuse access with judgment. If your team is suddenly able to build much more software than before, the next question is simple. What operating standards, review loops, and AI implementation discipline do you have around that new capability? If the answer is “not much yet”, that is the work to do next.


Title: Stop Fixing the Same AI Mistake Twice
URL: https://formationxyz.com/blog/stop-fixing-the-same-ai-mistake-twice/
Published: 2026-04-16
Author: XYZ by FORMATION
Description: If your team keeps correcting the same AI writing mistakes by hand, the real problem is not the draft. The real problem is that your editorial workflow has not turned the lesson into a rule.
Body: Many teams still use AI in a way that repeats the same corrections. An article draft comes back weak. The team corrects it. The next draft makes a similar mistake. The team corrects it again. The copy improves, but the workflow does not. That is an expensive way to run content operations. If an AI writing workflow fails in a repeatable way, the useful response is not only to fix the draft. The useful response is to turn the failure into a rule, checklist, or workflow note that reduces the chance of the same problem showing up again. This is one of the most practical AI habits, and it is still underused. Too many teams treat every bad output as a one-off annoyance. They patch the sentence, move on, and pay for the same mistake again tomorrow. A Concrete Example We have a repo-local skill called copy-tone. It exists because we got tired of correcting the same kind of bad AI writing over and over. The problem was not grammar. The problem was repeated marketing-style habits that weakened otherwise useful drafts: inflated language, fake drama, empty contrast, self-answering transitions, and polished phrases that sounded impressive without saying much. The pattern is familiar. “It is not just a website. It is a platform.” “The key point is …” “This is why …” “The result is a seamless, powerful experience.” That style is common because models have seen a lot of it. It is also weak. It creates motion without adding information, and it forces an editor to keep removing the same kinds of sentences by hand. So instead of fixing those habits one draft at a time, we turned the frustration into instructions. The copy-tone skill bans empty rhetorical contrast, vague cadence phrases, and filler language. It tells the model to prefer direct statements, concrete claims, operating constraints, and observable results. That changes the job. The model is no longer being asked to produce something vaguely good from scratch every time. It is being asked to work inside a clearer editorial system that reflects how we want publishable copy to read. The Real Lesson One corrected sentence improves one sentence. One good rule removes a recurring class of bad output from future drafts. A repeated AI failure is not just an irritation. It is design feedback. When a model keeps going wrong in the same direction, the next move is to ask what rule was missing. Was the standard implied instead of stated? Was the workflow missing a review step? Did the system have too much room to improvise badly? Once you see the pattern, make it explicit. Ask the model to describe the failure, propose a guard rail, and rewrite the instruction that should have existed before the mistake happened. Then review that rule properly before trusting it. Not every annoyance deserves a new policy. Some failures are one-offs. But when the same problem shows up across multiple drafts, it belongs in the system. That pattern shows up well beyond tone. Our translation-guide exists because multilingual publishing gets messy fast unless structure, slugs, thumbnails, metadata, and meaning stay aligned across languages. Our update-site-chat workflow exists because a published article should not leave the site bot behind with stale knowledge. Our verification step exists because publishing should trigger checks instead of relying on memory. That is how we orchestrate content publishing. Publishable content sits inside a system with instructions, generated knowledge, locale rules, and validation. In the normal publishing flow, we run checks that catch translation drift, front matter mismatches, and other content issues before the post is treated as done. When needed, we also regenerate the hidden chat knowledge so the rest of the site stays consistent with what was just published. Better content usually does not come from one good prompt. It comes from a better operating model around writing, review, translation, and publishing. If your team is producing articles, landing pages, or SEO content with AI but still spending too much time correcting the same problems, contact us . We can help you build the editorial rules, review flow, and publishing system that make the output more consistent and easier to trust.


Title: Why Agentic Workflows Need Payment Layers
URL: https://formationxyz.com/blog/agentic-payment-layers/
Published: 2026-04-15
Author: XYZ by FORMATION
Description: Agentic workflows stop at the point of purchase unless they have a controlled way to pay, with scoped permissions, spend limits, isolated records, and human review where it matters.
Body: Most discussion about agentic workflows still focuses on reasoning, orchestration, memory, tools, and approvals. Those pieces matter, but they are not enough once a workflow reaches a point where the system needs to spend money. That step is where many otherwise promising AI workflows still break down. The agent can find the right supplier, compare options, check timing, prepare the request, and recommend the next move. Then a person still has to step in with the payment method. In some workflows that is a small inconvenience. In others it means the workflow is not truly operational yet. If agents are going to handle more of the real work inside a business, they need a practical way to make bounded purchases on behalf of the company. That does not mean giving an agent broad access to the main corporate card or a generic finance login. It means giving a specific agent, inside a specific workflow, tightly defined rights to spend in a narrow context, with a clear cap, clear records, and a clean way to shut that access off. That is the role of an agentic payment layer. The Missing Layer In Many AI Workflows Most business workflows eventually touch money. A travel agent may need to book a train or hotel. A procurement agent may need to order a low-cost replacement part. A marketing agent may need to buy a small dataset, renew a software subscription, or place a tightly constrained ad spend. A customer support workflow may need to issue a refund or credit under a defined threshold. Without a payment layer, the workflow stops at recommendation. With one, the workflow can continue through execution. That distinction matters because many of the gains in closed-loop systems only appear when the loop can actually finish the job. A system that can research, decide, and prepare but cannot pay still leaves operational friction at the most sensitive point. What A Good Agentic Payment Layer Actually Does A useful payment layer should let a business assign very small, clearly defined purchasing rights to one agent or one workflow. It should also provide the means of payment inside that boundary. In practice that usually means controls such as: spend caps for the agent, workflow, or period merchant or merchant-category restrictions single-use or tightly scoped virtual cards isolated transaction records for that one agent and use case clear ownership, review, and shutoff controls Those controls are not optional polish. They are what make the workflow governable. An agent that books shipping labels should not be able to buy software. An agent that renews one approved SaaS tool should not have access to general procurement. An agent that can issue a refund up to a narrow threshold should not also be able to place fresh outbound spend somewhere else. Once agentic workflows are allowed to spend, their authority needs to be carved up as carefully as their task scope. This is also where payment records matter. If each agent or workflow has its own isolated trail, finance and operations teams can see what happened, why it happened, and which system initiated it. That makes auditing, rollback, exception handling, and policy refinement much easier. It also keeps one experiment or one specialist workflow from contaminating the records of everything else. Why This Matters Now This category is still early, but the shape of the problem is becoming clearer. Ovra describes itself as EU-native payment infrastructure for AI agents, with virtual cards and GDPR-compliant handling built in. That framing is useful because it treats agent payments as a distinct operations problem rather than as a small extension of employee expense tooling. Stripe Issuing is also explicit about the underlying control model for agents. Its current product language highlights single-use cards, spend limits, merchant-category controls, and real-time blocking for agents spending on the internet. That is exactly the kind of containment logic this category needs. The card networks are moving in the same direction. In April 2025, Visa announced that AI agents will need to be trusted with payments by users, banks, and sellers. In March 2026, Mastercard and Santander announced a live end-to-end payment executed by an AI agent within predefined limits and permissions. Those moves do not prove that the market is mature. They do show that serious payment players are treating controlled agent payments as a real implementation area. Agentic Workflows Need Payment Rights, Not Just Tool Access A lot of current agent design still assumes that tool access is the main question. Can the agent read the CRM, browse the web, update the spreadsheet, open the issue, send the message, or edit the repository? For a growing share of workflows, that is no longer the whole picture. The agent also needs limited permission to spend. That means defining a small, explicit spending boundary around the job. This agent may spend up to this amount. It may buy from these approved suppliers. It may act only inside this workflow. It may do so only while a certain budget is available. It may require human approval above a threshold. It may only use the payment method attached to that one use case. Once that boundary exists, the agent can complete real business tasks instead of stopping at a recommendation. Code-centric AI workflows make that easier because the workflow, rules, budget logic, and review points can all be made explicit and reviewable. Where Teams Will Feel This First The early use cases are likely to be narrow and practical. Teams will use payment-enabled agents for repetitive low-risk purchases, bounded refunds, software renewals, logistics bookings, sample orders, and supplier transactions below a defined threshold. They will not start by giving one general-purpose agent freedom to roam across the company bank account. They will start with specialist agents that have one job and one spending boundary. That pattern fits the broader direction described in our practical guide to major agentic systems . The most useful business systems pair autonomy with constraints, inspection, and review. If the workflow includes spending money, the system needs a payment setup that follows the same discipline as its sandboxing, approval gates, and workflow-specific instructions. The Operating Question For Businesses The business question is no longer only whether an agent can perform a task. It is whether the task includes money movement, and if it does, whether the company has a safe way to delegate that narrow spending action. Teams that solve payment delegation cleanly can automate more of the workflow end to end. Teams that do not will keep their agents stuck at the recommendation stage. The category still needs refinement, but the implementation pattern is already visible: bounded authority, controlled instruments, isolated records, and explicit oversight. If your team is building AI agents for business workflows that need to complete purchases, refunds, bookings, or procurement steps, this is the operational question to answer early. Who is allowed to spend, on what, up to which amount, through which instrument, and with what review path. If those controls are clear, the workflow can move from recommendation to execution without losing control.


Title: Skill Trees for AI Users
URL: https://formationxyz.com/blog/skill-trees-for-ai-users/
Published: 2026-04-14
Author: XYZ by FORMATION
Description: AI value does not come from one magic prompt. It comes from the skills users build over time, from asking better questions to designing repeatable workflows.
Body: Many people think of AI capability as a choice between different tools or models. In practice, operator skill matters more. Two people can use the same tool and get very different results because one knows how to structure the work and the other does not. Moving from prompting to agentic workflows means learning a sequence of skills. Trying to take shortcuts here does not really work. You can switch tools, but you still need to figure out how to use them. Most of these tools also look very similar to users who have not progressed far in that learning yet. This article looks at the skills people need to become effective with agentic workflows and how each one builds on the last. Role-playing games often organize abilities in a skill tree. You start with basic abilities and unlock more advanced ones as you progress. That is a useful way to think about agentic work as well. For most users, the issue is not tool access. No product produces reliable outcomes on its own. You need to learn how to ask, what to ask for, when to correct, and how to get repeatable results. AI systems often give you exactly what you asked for, even when the answer is wrong. Hallucinations, weak grounding, and false confidence are still common. Skilled operators catch and correct those failure modes consistently. The Skill Tree Most users start at the bottom of this progression because that is what they already know. They have used ChatGPT or similar tools to ask questions, summarize documents, or draft text. They have also seen the limits: convincing answers that are wrong, missing sources, weak grounding, and outputs that fall apart once the task gets more specific. The next layer starts when users stop treating AI as a one-shot answer machine and start giving it bounded tasks, better context, and clearer review criteria. From there, the progression moves toward repeatable workflows, delegated systems, and changes to how teams organize the work itself. It is also still early. Many AI users are still building these skills, and much of the market is still experimental. The further you move up this progression, the less polished the experience often becomes. That is especially true for tools designed mainly for users who still operate at the bottom of the skill tree. At XYZ by FORMATION, we help people and teams adopt agentic workflows with pragmatic coaching focused on getting real work done. We have spent a lot of time testing the skills in this tree, trying different tools, and learning what works in each context and what is still rough. ⤢ Open full screen flowchart TD subgraph L0["One-Shot Prompting"] direction LR A1["Task framing"] A2["Role prompting"] A3["Few-shot prompting"] A4["Source retrieval"] A5["Citation asking"] A6["Answer review"] A7["Hallucination spotting"] A8["Output specification"] end subgraph L1["Simple Agents"] direction LR B1["Task decomposition"] B2["Context packaging"] B3["System prompts"] B4["Agent instructions"] B5["Tool selection"] B6["File and repo grounding"] B7["Step planning"] B8["Artifact review"] end subgraph L2["Workflows and Guard Rails"] direction LR C1["Workflow design"] C2["Guard rail design"] C3["Structured outputs"] C4["Eval design"] C5["Retry and fallback logic"] C6["Approval gates"] C7["State and memory design"] C8["Scheduling and alerting"] end subgraph L3["Delegation and Control"] direction LR D1["Delegation design"] D2["Role design"] D3["Supervisor patterns"] D4["Context handoffs"] D5["Approval routing"] D6["Permission design"] D7["Queue design"] D8["Escalation paths"] end subgraph L4["Organizational Transformation"] direction LR E1["Function redesign"] E2["Workflow ownership"] E3["Governance"] E4["Operator training"] E5["Change management"] E6["Cost and risk controls"] E7["Cross-functional integration"] E8["Capability rollout"] end A1 --> B1 --> C1 --> D1 --> E1 A2 --> B2 --> C2 --> D2 --> E2 A3 --> B3 --> C3 --> D3 --> E3 A4 --> B4 --> C4 --> D4 --> E4 A5 --> B5 --> C5 --> D5 --> E5 A6 --> B6 --> C6 --> D6 --> E6 A7 --> B7 --> C7 --> D7 --> E7 A8 --> B8 --> C8 --> D8 --> E8 B2 --> C7 B3 --> C2 B5 --> C4 B6 --> C3 C4 --> D3 C5 --> D8 C6 --> D5 C7 --> D4 One-Shot Prompting This is ordinary ChatGPT-style usage: prompt an article, research a topic, answer a question, summarize a document, brainstorm options. The work is still mostly single-turn or lightly iterative. The model is not being asked to operate for long or manage a process. Skills in this layer: task framing: defining what the model should do and what it should ignore role prompting: giving the model a useful stance without pretending that roleplay is a method on its own few-shot prompting: using examples to show the pattern you want source retrieval: pulling in the right documents, references, and assumptions citation asking: requesting traceable support instead of smooth unsupported claims answer review: checking whether the output actually answered the question hallucination spotting: catching confident fabrication and weak grounding output specification: asking for a usable structure instead of a blob of prose What people usually miss here is that good prompting is not one trick. It is a bundle of small operator habits. This layer buys speed. It does not yet buy reliability or leverage. Simple Agents This is where agentic work starts. The user stops asking only for text and starts giving the system bounded jobs: deep research, small scripts, UI prototypes, repo inspection, structured drafts. The shift is from asking for an answer to assigning a job. Skills in this layer: task decomposition: breaking one large ask into bounded steps the agent can actually finish context packaging: supplying the files, screenshots, examples, and references the run depends on system prompt design: defining durable behavior and priorities before the run starts agent instruction writing: telling the agent what good looks like, how far it can go, and when it should stop tool selection: choosing the right tools and asking the agent to inspect before it acts file and repo grounding: anchoring the work in the actual documents, code, or assets involved step planning: making the agent sequence work instead of thrashing across tools artifact review: asking for a reviewable script, draft, prototype, or report rather than opaque output Vibe coding belongs here. It is prototype speed, not production discipline. Andrej Karpathy’s Vibe coding MenuGen captures both sides well: extreme speed early, then friction the moment real engineering concerns arrive. What people usually miss here is context engineering. The agent is only as good as the job boundary, the instructions, and the materials you give it. This is where tools like Claude Cowork Setup , Codex Setup , Agentic Slides , Proposal and RFP Assistant , Meeting Prep and Decision Pack , and Due Diligence Room Assistant fit. Workflows and Guard Rails Now the work gets wrapped in checks, timing, and standards. The operator is no longer chasing isolated wins. They are building a repeatable routine that can survive real usage. Skills in this layer: workflow design: deciding where the agent starts, what it does, and what counts as done guard rail design: defining constraints, checklists, and forbidden actions before execution starts structured outputs: forcing results into forms that downstream steps can reliably inspect eval design: setting rubrics, failure conditions, and test cases instead of relying on taste retry and fallback logic: deciding what should retry, what should degrade gracefully, and what should stop approval gates: defining where humans review, approve, or reject state and memory design: deciding what the workflow should remember between runs and where it should store that state scheduling and alerting: deciding what should run on cadence, what should interrupt, and what should wait for review This is where Closing the Loop and The End of Notifications become directly relevant. It is also where services like Agentic Content Management , Sales Follow-Up Operator , Pipeline Review Copilot , Board Pack Copilot , Exec Briefing Agent , Investor Update Engine , SEO Manager , QA Tester , Security Officer , and Webmaster fit. What people usually miss here is that reliability comes from design outside the prompt. This layer buys reliability. Delegation and Control At this point the problem is no longer one agent and one task. The problem is decomposition, routing, approvals, and handoffs across roles, systems, and people. Skills in this layer: delegation design: deciding what should be delegated, what should stay local, and what should never be autonomous role design: decomposing work into specialist agents and human responsibilities supervisor patterns: using a coordinating role to inspect, route, and contain work context handoffs: managing context transfer across people, tools, and channels without dropping critical state approval routing: deciding which steps can act, which need review, and which only advise permission design: matching tool and data access to the role instead of granting blanket power queue design: routing exceptions, triage, and ownership when work piles up escalation paths: deciding what happens when confidence drops, risk rises, or a workflow gets stuck This is where OpenClaw Setup , Engineering Team Agentic Setup , Agentic Website , Market Intelligence , and Company-Wide Agentic Workflow fit. It is also where Why Code-Centric AI Workflows Will Outperform Traditional Business Tools and How AI Can Pull Dev and Ops Teams Out of DevOps Hell fit cleanly into the argument. Agentic engineering belongs here. The work is harness design, tool permissions, review surfaces, interface contracts, queues, and failure handling. OpenAI’s Harness engineering: leveraging Codex in an agent-first world and Simon Willison’s How coding agents work are strong references on that shift. Organizational Transformation This is the point where AI stops being a productivity layer and starts changing how the work is organized. The question is no longer whether one workflow performs well. The question is whether a function can be redesigned around agentic systems, with clear ownership, controls, budgets, training, and failure handling built into normal operations. Skills in this layer: function redesign: reshaping one business function so the work can move through a governed agentic structure workflow ownership: deciding who owns results, failures, budgets, and improvements governance: defining controls, reporting, auditability, and exception handling around live autonomous work operator training: teaching people how to run, review, and improve these systems change management: changing incentives, habits, and interfaces instead of layering AI onto old habits cost and risk controls: treating spend, model risk, security, and compliance as operating constraints cross-functional integration: aligning handoffs, incentives, and system boundaries across teams instead of within one workflow capability rollout: sequencing change and extending the model without losing control This is where the services stop being about one setup and start being about operating redesign. Small Autonomous Organization and Complex Autonomous Organization turn one function into a governed operating unit. Company-Wide Agentic Workflow changes how a team works together in practice. Company-Wide Agentic Deep Dive is the broader transformation move across multiple functions. Roadmap Agentic Review and Your Agentic Use Case help decide where that redesign should start. Skills Hidden Inside the 28 Services FORMATION XYZ offers around 30 services to help companies get started with AI. To make that catalogue easier to navigate, we label services as starter, intermediate, and advanced. Those labels are not product tiers. They are shorthand for the operator skills a team needs in order to use the service well and keep getting value from it after the initial setup. That is the point of the skill tree. A service is not just something we deliver and walk away from. It is also a transfer mechanism for skills. If a team buys a workflow but never learns how to frame tasks, package context, review output, design guard rails, or manage handoffs, then the workflow stays dependent on outside help and eventually degrades. What we do is as much about coaching and teaching as it is about helping you automate work. Operating a company is a team job. The long-term win is not one clever workflow. It is getting the people across that company to level up their judgment, operating habits, and practical AI skills so the systems keep improving after we leave. This is also why AI work cannot be treated like a side errand for the youngest person in the room or a novelty delegated to an intern. The useful gains come when the people who own the work learn how to operate the systems around that work. Sales leaders need to understand review loops and handoff quality. Engineering leaders need to understand context, permissions, and harness design. Operators need to understand when to trust a system, when to inspect it, and when to stop it. So the service catalogue is best read as a set of entry points into the skill tree. Some services help a team build basic prompting and bounded agent skills. Others help teams move into workflows, approvals, evals, and recurring operations. The most advanced services are not really about AI tooling at all. They are about helping a company redesign how work is owned, reviewed, and improved. What This Means In Practice The point of this tree is simple: AI value grows as operator skill grows. The real gains come when teams move beyond isolated wins and start building the habits, workflows, and judgment that make good results repeatable. If your team is still in one-shot prompting mode, that is a perfectly valid place to start. If you can already run bounded tasks with simple agents, the next step is usually to add workflows with guard rails, evals, approvals, and recurring review. And once those patterns start working, the opportunity shifts again: from isolated use cases toward redesigning ownership, controls, and team routines around agentic systems that can be trusted. That is where FORMATION XYZ fits. We help teams automate useful work, but we also help them build the skills needed to operate that work well. The goal is not to leave you with a clever setup that only works while we are in the room. The goal is to level up your people so the systems become part of how the company works. Where you start depends on where your team is now and what is most urgent to improve. The hype around OpenClaw is huge right now, and for good reason. People are doing genuinely transformative things with it. But it also comes with real risks and real failure modes. OpenClaw is not just a tool install. It pushes teams straight into delegation, control, and organizational redesign, which means it exposes a lot of the skill tree very quickly. That is also why the value of something like OpenClaw is not just that you get the tool running. The value is that it gives your team a serious way to get its hands dirty with AI, build operator judgment, and work through the layers of skill that make larger transformations possible. For some teams that is the right place to start. For others, it makes more sense to begin with Claude Cowork for document and research workflows or Codex for repo-centric and technical workflows, then move upward from there. And not every team needs to start with a starter package. You may already have your preferred tools running and be looking for the next step in your agentic journey. Browse our services . See which ones feel most relevant. Then reach out. We will help scope what matters most, figure out the right starting point, and get your team moving. Learn More This article sits inside a broader argument on this site. In Closing the Loop , we make the case that useful AI systems are not just generators. They are loops with checks, corrections, and control points. In The End of Notifications , we push that further and argue that good systems should reduce interruption, not create more of it. Why Code-Centric AI Workflows Will Outperform Traditional Business Tools explains why structured files, repos, and reviewable environments matter so much when you want agents to do real work. How AI Can Pull Dev and Ops Teams Out of DevOps Hell shows what that looks like in operational practice, where the real gain comes from turning fixes, checks, and runbooks into reusable systems. If you want the speed side of this story, Hyper Agile and What if time to market was measured in hours or days instead of months or years? show what happens when teams can compress the cycle from idea to launch. If you want the cautionary side, The NRC affair shows why newsrooms need skills, not just AI tools makes the case that weak operator judgment does not disappear just because a model is involved.


Title: DECK/DOCS: How we make automatic sales decks & docs from basic deal data
URL: https://formationxyz.com/blog/deck-docs-sales-offers/
Published: 2026-04-09
Author: XYZ by FORMATION
Description: DECK/DOCS turns structured inputs such as scope, pricing, roadmap notes, contacts, and brand cues into polished offers, readable sales documents, and presentation-ready decks from the same source.
Body: Most teams still create offers, sales documents, and presentation decks as separate manual jobs. One version gets written for reading. Another gets rebuilt for presenting. Then both get reformatted, restyled, translated, and adjusted again when the offer changes. That is slow, repetitive, and more expensive than it should be. We built DECK/DOCS to remove that waste. DECK/DOCS takes simple structured data points and turns them into full sales material. The same source can generate a polished document for reading, review, and forwarding, and it can also generate a presentation-ready slide deck for the sales conversation itself. We are no longer maintaining one artifact for document work and another artifact for slides. We are maintaining one structured source that can be rendered in the mode that fits the situation. In practice those inputs can include the customer name, scope summary, validated POC status, rollout assumptions, pricing, roadmap notes, contact details, and client brand cues. The system assembles and renders that material, but a person still decides the commercial framing, checks the claims, and approves the final offer or deck before it goes out. The same structured source can render as a clean offer document for review, forwarding, and detailed reading. Slides and documents do different jobs. A document should be easy to read, scan, and share. A slide deck should pace attention, simplify hierarchy, and support a live conversation. Most teams know that, but they still end up rebuilding the same content twice. With DECK/DOCS, the content stays aligned because the system separates the source from the presentation logic. Content and Style Are Separated The core design decision was to separate content from styling. The underlying offer logic, factual inputs, metadata, and structure live in one layer. The visual system lives in another. That makes the workflow much more flexible. If the message changes, we update the content layer. If the visual treatment needs to change, we update the style layer. If both need to move, they can still move independently instead of turning into one tangled production problem. That separation also makes reuse realistic. Good structures do not disappear into old deck files. Strong layout logic does not stay trapped in one document. Once the system has a working structure, it can reuse it across new offers and new customer material instead of starting again from a blank page. The Same Source Becomes Slides or Docs One of the most useful parts of DECK/DOCS is that the same source can be viewed as slides or as a document without manual reassembly. We can feed the system simple metadata, source notes, offer components, and structural guidance, and it can generate a visually strong sales deck that also converts cleanly into a readable document. The team is not paying twice for the same thinking. The same content system supports both reading mode and presentation mode, and the review owner can inspect both outputs before anything is sent. The same offer logic can switch into deck mode, with hierarchy and pacing designed for the live sales conversation. This helps review too. Some people want to review a document because they need detail and context. Others want to see the sales deck because that is how the story will actually be presented. DECK/DOCS supports both without forcing the team to maintain two drifting versions. Language Becomes A Switch Another practical gain is multilingual output. Because the content is structured properly, we can switch a deck or document from English to German with a simple language toggle. Language becomes a switch instead of a separate production project. The structure stays intact. The styling stays intact. The underlying content logic stays intact. That removes a large amount of avoidable translation overhead and makes it much easier to keep customer-facing material aligned across both languages. For a team working in German and English, this removes a common source of version drift and formatting rework. In most sales workflows, bilingual output is where extra production work starts to pile up. DECK/DOCS cuts much of that rework because the language layer is built into the system rather than bolted on later. Client Branding Gets Easier Too We also use the style layer to adapt material to the visual language of a client. We can feed the styling workflow a client website and use it as input for structure and styling decisions. We are not only swapping a few colours. We are giving the system cues about hierarchy, tone, rhythm, and corporate identity so the generated deck starts much closer to the client context. A person still decides which cues matter, what to keep, and where the design needs correction. Client-aligned styling can carry through the full deck, including the closing slide and presenter handoff. That is especially useful for proposals, enterprise sales conversations, partnership material, and any situation where visual alignment affects trust. A small team can produce more tailored material without absorbing the usual cost of manual design adaptation every time. The Savings Are Already Clear The practical result is straightforward. DECK/DOCS already saves XYZ several days of production effort each month across offer assembly, slide preparation, translation, and design cleanup. The savings show up in all the places where teams normally lose time: duplicated formatting work, manual slide rebuilding, translation work, style cleanup, version alignment, and repeated offer assembly. Once the system carries more of that burden, the team gets faster output, cleaner consistency, and more room to focus on the quality of the actual sales story. Structured AI workflows matter when the inputs, layout rules, language layers, and review steps are explicit. That is what makes the output easier to reuse, easier to inspect, and cheaper to produce repeatedly. DECK/DOCS shows that pattern clearly. Simple inputs become polished offers. The same source becomes docs or slides. English becomes German with a switch. Client styling becomes easier to adapt. A workflow that used to consume repeated manual effort becomes much lighter to run. For XYZ, it is a practical operating workflow that makes offer production faster and easier to control.


Title: The Making of the XYZ Website
URL: https://formationxyz.com/blog/the-making-of-the-xyz-website/
Published: 2026-04-09
Author: XYZ by FORMATION
Description: Instead of treating the XYZ site as a static brochure, we built it as a promptable website with explicit guard rails, a structured content pipeline, and an editor workflow that can move much faster without losing control.
Body: Instead of writing an article about how we created an agentic website for XYZ, we decided to ask it to introduce itself. That choice is slightly theatrical, but it also makes the point faster. This website was built as a promptable website: a site whose content, structure, knowledge layer, previews, and supporting automation all live in a form that AI can inspect and work on directly under clear constraints. That distinction matters. A lot of website AI still looks like decoration. A chatbot floats in the corner, maybe a few pages are AI-generated, and the rest of the site still behaves like a brittle hand-maintained object. We wanted something more useful. The site started as a clone of our existing Hugo-based tryformation.com setup, which we already maintain in an agentic way, but the design itself started from a clean slate using imagery and an opinionated design prototype by our CEO, Ian Hannigan. From there we registered the domain with Cloudflare, asked Codex to set up the deployment flow through GitHub Actions, and pushed the first version of the site live in about four hours. The Guard Rails The guard rails are the reason this works without turning into chaos. First, the site lives in a repository with a predictable structure. Pages, services, blog posts, navigation data, assets, and templates all have clear homes. That means AI is not guessing where things belong. It can inspect the current state, compare similar content, and make targeted changes instead of improvising across a vague CMS surface. Second, the repository carries explicit instructions. We keep workflow rules close to the work so the system knows the content source of truth, the translation expectations, the asset rules, the validation commands, and the tone. In practice this matters more than many people expect. The difference between a useful AI collaborator and a messy one is often not the model itself. It is whether the operating constraints are clear enough to make good decisions repeatedly. Third, we do not leave the output unbounded. The site is built through templates, generated knowledge, search indexes, and validation steps. So even when AI drafts copy or proposes structure, the result still has to fit the established system. That sharply reduces random drift. It also makes review easier because the output lands in inspectable files rather than disappearing into a SaaS interface somewhere. Fourth, we are selective about where live intelligence belongs. The little helper on this site does not run as an unrestricted live LLM. We prepare its knowledge layer, we shape likely answers, and we keep the runtime behavior narrow enough to stay fast, predictable, and cheap. That is a guard rail too. Sometimes the right AI decision is to move more intelligence upstream into the production process instead of into the visitor-facing runtime. The Content Production Flow The production flow is where the website starts behaving less like a brochure and more like a working system. We usually start from a practical need: a new service, a sharper explanation, a better landing page, a missing FAQ, a stronger article, or a new way for visitors to reach the right offer. From there, AI can inspect the current repository, understand how similar pages are structured, and draft new material directly in the same format the site already uses. That is how this site moved from first live version to something much richer over the following two weeks: more content, more features, tighter design, and a growing layer of useful detail instead of a long backlog waiting for developers. Because the content lives in markdown, JSON, templates, and reusable assets, the system can do more than write a first draft. It can connect a page to the right navigation, generate follow-on knowledge for search and the site helper, create social preview material, and preserve internal consistency across the site. The work is not trapped in one editor window. It flows through the full website stack. That also means improvements compound. A clearer service page improves the page itself, but it also improves internal search, the bot knowledge layer, linked content, and future editorial work because the better explanation is now part of the system. Once the site is structured this way, each good edit becomes reusable input for later edits. The current site helper is part of this flow. We generate and curate knowledge before the visitor arrives. We use overrides where we want tighter answers. We cache work where nothing changed. We keep the whole thing connected to analytics so the site can tell us what people are actually asking, where the navigation fails, and which topics deserve stronger treatment. That creates a loop between content production and observed demand. The same pattern also helped us move fast on features. One example we are particularly happy with is the audio transcription experience. We went from idea to prototype in a day, then refined the UX until visitors could read along with the text being highlighted. What This Changes For Editors For editors, the biggest change is the drop in cost and effort across the whole workflow. An editor can ask for a new article, a tighter headline, a more direct call to action, a new FAQ cluster, a campaign page, a search-oriented content pass, or a structural cleanup without starting from a blank page every time. AI can propose the first pass, compare it against the rest of the repo, and work inside the same patterns the site already uses. The editor stays in charge of judgment, but spends less time on repetitive assembly work. That is especially useful when the job is not purely textual. Editors often need surrounding operational help: update internal links, keep formatting coherent, align the navigation, reuse an existing image, add the right metadata, or make sure the page also helps search and retrieval. A promptable website lets AI help with those tasks in one pass because the surrounding system is available to inspect. There is also a speed benefit for ongoing maintenance. Websites drift because small jobs pile up. A few weak pages stay weak. An older article is still useful but badly linked. A service page no longer reflects how the offer is framed. The FAQ lags behind real conversations. In a promptable setup, those jobs become much cheaper to do, which means they are less likely to be postponed indefinitely. Editors also do not need to become developers to benefit from this. Ian Hannigan is not a developer, and he did almost all of the work on this site. Not needing a development team in the loop for every content change, design iteration, or feature idea removes most of the friction that normally slows a website down. The value is not that everyone suddenly writes templates by hand. The value is that the website is stored in a form where AI can do precise implementation work on behalf of the editorial and design owner. Why We Think This Matters We built the XYZ website this way because we wanted the site itself to demonstrate the operating model behind our services. If we are going to talk about agentic websites, promptable content systems, and AI-assisted editorial operations, the website should behave like one. This site is a success story for us. We did not use AI to cut corners. We used it to raise the ceiling. It helped us deliver a modern layout that feels right for the brand, advanced search and retrieval, a strong internal knowledge layer, and a content workflow that would have been much heavier to build and maintain the old way. We are also not treating the website as finished. We are constantly iterating on it because the friction is so low. New pages, sharper explanations, better navigation paths, stronger retrieval, and more targeted content can be added as soon as we see the need. At this point the site almost writes itself, not because humans disappeared, but because the system is set up to turn editorial intent into working output very quickly. The practical difference is straightforward. The website itself is designed to work productively with AI. The result is a site that can move faster, explain itself better, and keep getting better as we use it. If your website still behaves like a precious object that only changes through slow handoffs, there is a good chance the operating model is the real bottleneck. We can help build a promptable website around your content, your offers, and your editorial workflow so the site becomes easier to improve instead of harder.


Title: Hyper-Agile
URL: https://formationxyz.com/blog/hyper-agile/
Published: 2026-04-09
Author: XYZ by FORMATION
Description: Hyper-agile software development changes the bottleneck from implementation to judgment. With agentic coding and AI-native workflows, small teams can ship, test, and revise software within hours.
Body: For a long time, software worked like this: ideas were abundant, but implementation was scarce. Teams had more concepts than they had developer time, design time, budget, or organizational patience to execute. That imbalance shaped how companies planned. They prioritized heavily, ran long roadmaps, protected engineering capacity, and accepted that many potentially good ideas would simply never make it into reality. That balance is changing very quickly. We are moving into a period where the speed of implementation can overtake the speed of creativity. Not in every company yet, and not on every task, but often enough that it already changes how teams should think. With agentic coding tools, better orchestration, and AI-native development workflows, it is now realistic to go from rough idea to working software in the same hour. In some cases, that software can be deployed the next hour, shown to users immediately, and revised again before the day is over. That is not just agile development with a new coat of paint. It is something else. It is hyper-agile. It is closely related to the acceleration pattern we described in What if time to market was measured in hours or days instead of months or years? , but focused specifically on what happens once software teams can turn that shorter path into a normal way of operating. What hyper-agile software development actually means Hyper-agile software development means the loop gets so short that implementation stops being the main constraint. The interesting question is no longer, “Can we build this in the next quarter?” The interesting question becomes, “Is this idea good enough to deserve the next hour?” That sounds like a subtle shift, but it is not. It changes the economics of software. If a small team can turn an idea into a testable product surface almost immediately, then the scarce resource is no longer mainly developer throughput. The scarce resource becomes judgment. Which ideas are worth trying? Which signals matter? Which user complaints should trigger action? Which rough concept should be ignored even if it is easy to ship? That is also why idea quality and idea selection start to matter more, which is the same operating tension behind Getting Good Ideas Unstuck . Why small teams may gain first This is one reason small companies may benefit disproportionately. A small team that is already comfortable with fast decisions can absorb this new speed much more easily than a large company still stuck halfway between waterfall and agile. If a business already needs committee review, layered approvals, long briefing cycles, and scheduled release trains just to make a modest product change, hyper-agile will not feel liberating. It will feel destabilizing. For a lean team, though, it is a gift. A founder can spot an opportunity in the morning, shape it into a working product or service by lunch, put it in front of users that afternoon, and learn something commercially useful before the day ends. That kind of cycle used to be exceptional. Now it is becoming normal for teams that know how to work this way. The underlying reason is often not magic model performance on its own. It is the combination of agentic coding, reusable prompts, structured repositories, and the kind of operating setup we described in Why Code-Centric AI Workflows Will Outperform Traditional Business Tools . Why feedback loops become the product advantage The most striking part is how this changes the role of feedback. Recently, I had someone send over a list of issues with something I was building. In the past, that would have meant a small backlog, maybe a planning discussion, maybe a few days before the fixes landed. This time, I copied the feedback, turned it into a prompt, implemented the changes, and sent back an updated version almost immediately. The person on the receiving end was genuinely startled. They had not yet adjusted to the new pace. Then they sent more feedback, and the loop repeated. That kind of moment matters because it shows where we are heading. Feedback loops are getting compressed to the point where the distance between critique and revision can become negligible. That is a profound change. Users do not just influence the next major release. They can influence the next hour. This is also where our earlier argument about Closing the Loop becomes more important. Once software can be changed this quickly, it becomes possible to imagine systems that do more of the loop themselves. A product can collect feedback, cluster it, rank it, map it against current priorities, propose changes, implement bounded improvements, test them, and ask for more feedback after release. That is still a system that needs constraints, review, and business judgment. But the mechanics of the loop are becoming far more compressible than most teams are used to. The automated trading analogy is useful here. In trading, a system observes conditions, acts, measures the result, and acts again. More software will start to behave like that. Not because every product should become a reckless self-modifying machine, but because the friction around observing, deciding, implementing, and learning is collapsing. A useful piece of software may increasingly act like a small probe: launched quickly, exposed to reality, improved continuously, and kept current by the very signals it receives from its environment. That has serious consequences for how products are conceived. Teams need fewer monuments and more probes. Fewer multi-month internal projects designed to survive committee review. More live experiments designed to learn fast. In the old model, a company would spend weeks refining a concept before it ever met a user. In the hyper-agile model, it may be better to let the user meet a rough but functional version early and let the contact with reality do part of the shaping. Hyper-agile needs structure, not just speed Of course, speed on its own is not a strategy. Fast teams can still ship bad ideas at record pace. They can still misread weak feedback. They can still create noisy, unstable products if they treat motion as progress. Hyper-agile only becomes valuable when speed is tied to real signal and strong taste. When implementation gets cheaper, the differentiator becomes the quality of the thinking behind what gets implemented. That is also why fast iteration needs guardrails. Review habits, test coverage, deployment discipline, and operational boundaries become more important, not less, when the cycle gets shorter. Otherwise a team does not become hyper-agile. It becomes hyper-chaotic. That is the same operational lesson behind How AI Can Pull Development and Operations Teams Out of DevOps Hell . That may be the biggest shift of all. For years, software rewarded access to technical talent, headcount, and execution capacity. It still does, but the weighting is changing. If the path from concept to working version keeps shrinking, then the teams with the clearest ideas will increasingly outperform the teams with the largest machinery. Great ideas, sharp prioritization, and close contact with users become more important when the cost of turning thought into product falls this far. So yes, we are about to see the rise of hyper-agile. Ideas will become working software in hours. First users will arrive earlier. Feedback will land faster. Patch releases will happen sooner. Some products will start to maintain and improve themselves inside carefully designed loops. And many organizations will realize that their real bottleneck is no longer technology. It is how quickly they can generate, recognize, and act on good ideas. That is a very different world from the one most software teams were built for. The question is who will adapt first. If you could put one new idea into the market at light speed this week, what would you launch?


Title: What the Peter Van der Meersch Case Says About Responsible AI Workflows in Newsrooms
URL: https://formationxyz.com/blog/nrc-affair-shows-why-newsrooms-need-skills/
Published: 2026-04-07
Author: XYZ by FORMATION
Description: The Peter Van der Meersch case is best understood as an AI workflow failure. The practical lesson is not to avoid AI altogether, but to use supervised AI workflows with verification loops, guard rails, and clear accountability.
Body: For readers outside the Netherlands, a little context helps. NRC is one of the main Dutch newspapers. Peter Van der Meersch is a well-known senior media figure who previously led NRC and later held senior roles within Mediahuis in Ireland. That is one reason this story travelled beyond the Dutch press and into English-language coverage as well. The facts of the case are straightforward. NRC investigated Van der Meersch’s use of AI in his own newsletter work and reported that fabricated quotations had been published. The Guardian then reported on 20 March 2026 that Mediahuis had suspended him from his fellowship role after NRC’s findings, and that several quoted people said they had not made the statements attributed to them. In his own response, Van der Meersch wrote: “I summarised reports using AI tools and worked from those summaries, trusting they were accurate.” and: “I wrongly put words into people’s mouths” Source: Columbia Journalism Review and NL Times . Van der Meersch’s apology matters because he is acknowledging a real editorial failure. At the same time, the mistake was not only that he trusted the output too much at the end. Our reading is that the workflow itself was too loosely instructed and too weakly verified. He was clearly using tools such as ChatGPT, but there is no sign here of a more agentic workflow that would automate parts of the checking around quotes, claims, and source references before publication. That gap is not unique to one editor. It is common across much of the news industry and across white-collar work more broadly. Software engineers have moved faster into agentic workflows and have spent more time getting used to delegating meaningful work to AI systems under review, with logs, tests, and explicit approval points. Many other professions are still earlier in that transition. The issue is operational. There was no reliable loop that forced the draft back to source evidence before publication. That is exactly why incidents like this are useful to study. They show where an agentic workflow could have helped by automating parts of the verification work that were apparently left undone. If a team wants to use AI responsibly, it cannot rely on a vague instruction to “check the output carefully.” That is not a system. A system needs explicit stages. It needs rules for what AI may do, what it may suggest, what it may never invent, and what must always be tied back to primary material. It needs structured handoffs between drafting and verification. It also needs a hard stop when evidence is missing or weak. Skills and agentic workflows matter here because they turn that kind of control into written procedure. The useful systems are not just drafting tools. They are loops with checks, corrections, and repeatable control points. In a responsible editorial or knowledge workflow, “please verify” is not enough. AI can help collect source material, compare versions, draft working notes, and prepare a first pass. But any direct quote has to carry its source with it: transcript or recording reference, speaker name, date, and the exact passage it came from. If a generated quote does not match the source wording exactly, it cannot be kept as a quote. It either becomes a paraphrase with attribution, or it gets deleted. Every factual claim about dates, roles, events, numbers, and allegations needs the same treatment. The model can draft the sentence, but the workflow must attach the evidence before the sentence survives. A verification step checks whether every quote and claim has evidence attached, and anything unsupported is blocked rather than left hanging for later. A final human reviewer should see not only the polished draft, but also the evidence trail and any unresolved exceptions. The output is published only after the workflow has either cleared those checks or explicitly escalated unresolved issues. That can be implemented without much ceremony. An editorial-verification skill can require the model to extract every direct quote, attach the source document, speaker, and timestamp or paragraph reference, and flag any wording that does not match exactly. The same skill can require every non-trivial factual sentence to carry a source note. A publication step can refuse to proceed if any quote or claim still lacks evidence. The same logic applies in article workflows more broadly. A publishing skill can treat critical review as a gate, not a courtesy pass, and pair that review with an explicit verification pass for quotes and claims. The review should stay hostile but fair, focused on weak claims, unsupported statements, structural confusion, SEO vagueness, and lines that sound polished without being grounded. For this kind of article, that review should also ask two simple questions: which claims are still too weak for publication, and which quoted lines have not been verified against the source. That kind of setup is not limited to journalism. The same pattern matters in research, policy, legal review, compliance, investor communications, and internal reporting. Anywhere an organisation wants AI to help with high-trust material, the question is straightforward: where is the loop that catches bad output before it becomes public or operationally binding? AI can make that work faster and more efficient, but it does not take over the accountability. The final responsibility still sits with a person, and in practice that means the reputation on the line is still human as well. Our view is that responsible AI adoption starts there. Not with hype or blanket bans, but with shaping the work into a process that can be guided, verified, and improved over time. That is what we mean by an agentic workflow. If your team is trying to use AI responsibly in real work processes, the practical questions are usually the same: where the evidence sits, who verifies what, and which step can block publication when the draft outruns the source material. That is where skills, guard rails, and review flows start to matter. Helping teams make that shift is part of our work, and it is also why we thought this case was worth using as a concrete example. If that is the kind of approach you are looking for, talk to us .


Title: The End of Notifications
URL: https://formationxyz.com/blog/end-of-notifications/
Published: 2026-04-02
Author: XYZ by FORMATION
Description: Agentic systems are better suited to brief us than to interrupt us, which is why the daily digest is likely to overtake the notification as the default way digital systems surface new information.
Body: Most notifications are not urgent. They arrive with the tone of urgency, but very few of them justify interrupting a meeting, a phone call, a train ride, a dinner, or a quiet hour of focused work. The current notification model assumes that every fresh piece of information deserves a chance to break into the foreground. In most cases that is simply a bad operating model for human attention. What people usually need is not more interruption. They need better compression. They need a system that can collect fragmented information throughout the day, identify what actually matters, rank it, group it, discard the trivial parts, and present the useful remainder in a form that is quick to scan and easy to act on. This is exactly the kind of task agentic systems are well suited to handle. That is why the daily digest is likely to become the predominant way we are alerted about new things. Instead of forcing us to process a stream of scattered pings, the system can deliver a briefing. It can tell us what changed, what matters, what can wait, what deserves a decision, and what should be ignored entirely. The shift is not just cosmetic. It changes the basic contract between person and machine. The useful analogy is not social media. It is the executive briefing. Think about a personal assistant entering a chief executive’s office with a concise digest: the important developments, the open issues, the few decisions that need attention, and the background context that may become relevant later. Or think of the presidential daily brief. That structure exists because decision-makers benefit more from prioritised synthesis than from a raw stream of interruptions. Agentic systems make that model available much more widely. They can watch inboxes, calendars, project systems, competitors, analytics, customer messages, internal updates, and external events at the same time. Then they can condense all of that into a coherent morning briefing, an end-of-day summary, a weekly Monday planning note, or a targeted digest ahead of a key meeting. The system does not merely forward information. It interprets it operationally. Of course, there will still be exceptions. A fire alarm is not a digest item. A severe outage, a security incident, a broken payment flow, or a real emergency may still need to break through immediately. But those cases should become rarer, not because the world is calmer, but because the surrounding agentic system can often respond first. It can classify the issue, trigger mitigations, gather evidence, and escalate only when the situation actually warrants human interruption. That is why I think the digest will do to the notification what television did to radio in everyday life. It is a fundamentally better format for most of the job. It carries more context, more prioritisation, and more judgment. A notification says, “something happened.” A digest says, “here is what happened, here is why it matters, and here is what you may want to do next.” That is a much more useful unit of information. The deeper point is that agentic systems are not only changing what gets automated. They are changing how human attention is managed. A good system will increasingly shield us from noise instead of manufacturing more of it. In that world, everyone gets some form of daily briefing, and the old notification layer starts to look like a crude transitional technology that made sense before software became capable of acting more like a chief of staff.


Title: Closing the Loop
URL: https://formationxyz.com/blog/closed-loop-systems/
Published: 2026-03-29
Author: XYZ by FORMATION
Description: Closed-loop systems turn agentic workflows into repeatable labor by moving work through research, execution, testing, reporting, and iteration without dropping context.
Body: Most teams still talk about agents as if the interesting part were the conversation. It is not. The interesting part is the workflow. A closed-loop system is what turns an agentic setup from a clever interface into actual labor: a task enters the system, agents move it through a defined sequence of steps, and the system produces a real output that can be checked, shipped, or used. That loop can be linear or non-linear. One agent may inspect a problem, another may classify it, another may propose a fix, another may implement it, and another may verify the result. In more advanced systems, the path branches. A failed verification can send the work back to engineering, a weak research result can trigger more investigation, and a low-confidence answer can escalate to review. What matters is not the shape of the path but the fact that the path closes. This is why a bug-finding loop is such a useful example. An agent can monitor logs, detect regressions, open an issue, reproduce the failure, generate a patch, run tests, confirm the fix, document what changed, and then resume watching the system. Once that chain is stable, you no longer have isolated automations. You have a working cycle of maintenance. Websites are one of the clearest early examples because they already sit inside structured systems: repositories, content folders, analytics, search data, deployment pipelines, and validation checks. A closed-loop website can keep itself current by finding broken links, updating stale copy, improving search visibility, refining page structure, and feeding what it learns back into the next round of changes. It starts to behave less like a static asset and more like an operating system for the business. The same logic applies even more strongly to SaaS products. A product can observe user behavior, collect support feedback, compare competitor changes, identify gaps, draft feature specs, implement bounded improvements, test them, release them carefully, and then measure the effect. If the loop is designed well, the product is not only being maintained. It is also learning from its environment and using that learning to evolve. This is where productivity changes meaning. In a closed-loop system, productivity is not just faster output from one model or one employee. It is the ability to keep work moving through a chain of specialized roles without losing context, standards, or momentum. Each pass through the loop creates another unit of useful labor, and the system can keep running long after a human has defined the rules, approvals, and constraints. That points to a different future for software. Instead of software being a passive tool that waits for human operators, more of it will behave like an active economic unit around a narrow mission. A website can maintain and improve itself. A product can observe, propose, test, and refine itself. A service business can run specialist loops around sales, delivery, support, reporting, and content. The software does not need mystical general intelligence to do this. It needs structure. The practical challenge is to design loops that stay useful instead of becoming expensive motion. That means clear handoffs, explicit quality checks, scoped permissions, and outputs that can be measured against business goals. Teams that learn to build these loops well will not just use agentic systems as assistants. They will use them to create self-improving operational surfaces, which is much closer to the real future of software. One useful mental model is automated trading. In financial markets, a system observes conditions, places trades, measures outcomes, adjusts, and runs the next cycle without pausing to admire its own logic. SaaS growth systems already work in a similar way at a slower human pace: teams change a landing page, adjust a funnel, measure conversion, refine the message, and run the next experiment. That is already a closed loop. The difference now is that companies can engineer agentic workflows to determine the next best action by themselves based on what their previous changes actually did to the profitability of the service. When the loop is pointed at the right goals, constrained properly, and allowed to keep learning, it stops being a helpful automation and starts becoming a compounding system for growth.


Title: A practical guide to the major agentic systems
URL: https://formationxyz.com/blog/major-agentic-systems-guide/
Published: 2026-03-19
Author: XYZ by FORMATION
Description: A practical overview of major agentic systems, what unifies them, where they differ, and why guard rails matter more than tool hype.
Body: As of March 19, 2026, the field of agentic systems is moving fast enough that many teams see a blur of demos, names, and screenshots but still do not have a clean way to compare what these systems actually are. The useful distinction is usually not “which model is smartest” but “what kind of operating surface does this tool provide, how much autonomy does it have, and what controls sit around it?” At a high level, OpenClaw, NanoClaw, and NanoBot are the systems we help clients put to work directly. Claude Code, Claude Cowork, and Codex are broader external systems that represent where this class of tooling is heading. They all sit in the same family because they move beyond one-shot prompting and toward delegated multi-step work with tool access, file access, instructions, and reviewable execution. Here is a practical comparison table to keep the main differences straight: System Best fit Operating surface Strength Caution OpenClaw Teams that want a broader agentic operating layer Multi-workflow operations across tools and processes Shared controls, reusable workflows, stronger operational reach Needs more workflow design and setup discipline NanoClaw Small teams that want a lighter agentic workbench Compact multi-workflow setup Faster rollout with more flexibility than a single bot Less comprehensive than a broader platform layer NanoBot Teams with one bounded workflow to automate Single specialist workflow Fast, narrow, concrete value Scope is intentionally limited Claude Code Engineers working inside repositories and terminals Repo, shell, files, coding workflows Strong fit for code-centric, inspectable work Can be too technical without a clear operating model Claude Cowork Broader knowledge work with long-running tasks Claude Desktop with local files and task execution More accessible surface for non-coding tasks Broader file access and task autonomy need tighter oversight Codex Teams that want a configurable coding-agent environment App, CLI, IDE, repo, shell, skills, subagents Strong control model around instructions, skills, approvals, and sandboxing Still depends heavily on good repo hygiene and review practices OpenClaw is best understood as a fuller operating layer. It is useful when a team wants multiple workflows, shared controls, reusable patterns, and a system that can sit closer to day-to-day operations. NanoClaw is the lighter-weight sibling: more flexible than a single specialist bot, but smaller and faster to roll out than a broader platform setup. NanoBot is narrower still. It is the right fit when one workflow such as intake triage, document preparation, or lead qualification deserves a focused agent of its own. Claude Code is a strong terminal-first coding agent for people who want the agent inside a repository and command-line workflow. Anthropic emphasizes subagents, hooks, permissions, and memory files in its Claude Code documentation, which makes it especially useful when a team wants coding work to live inside a structured, inspectable environment. Claude Cowork uses the same agentic architecture inside Claude Desktop for broader knowledge work. Anthropic describes it as a research preview that runs tasks on your computer, can coordinate sub-agents, uses a VM environment, and supports plugins, scheduled tasks, and file access for longer-running work beyond coding. Codex sits in a similar category on the OpenAI side: a coding agent ecosystem built around agentic coding models, AGENTS.md instructions, skills, subagents, approval policies, and sandboxing modes that range from read-only to dangerous full access. The pros and cons follow from that positioning. OpenClaw is strong when you want a serious operating layer, but it asks for more setup and workflow design. NanoClaw is easier to adopt and easier to control, but it is not trying to be a company-wide platform on day one. NanoBot is fast and concrete, but intentionally narrow. Claude Code and Codex are excellent for engineering-heavy environments because they work well with repositories, shell tools, instructions, and repeatable workflows, but they can be overkill for non-technical teams if nobody designs the operating model around them. Cowork broadens that access for knowledge work, but because it reaches into local files and long-running tasks, it introduces a different risk profile and requires even more discipline around permissions and oversight. It is also worth acknowledging the current friction directly. Setup is still harder than it should be. Many of the strongest tools still assume a developer-friendly environment, and a lot of the best patterns today emerge in repositories, terminals, structured files, and scripted workflows before they show up in smoother business interfaces. That can feel like an argument for waiting. We think it is usually the opposite. The common feature set is what really defines this class of systems. They usually have an instruction layer such as AGENTS.md, CLAUDE.md, folder instructions, or global rules. They often support subagents or specialized workers to split tasks. They can use tools, file systems, connectors, or shell access instead of only generating text. They increasingly support reusable skills, plugins, slash commands, scheduled tasks, hooks, or background execution. And they work best when the environment around them is structured enough that the agent can inspect the current state, apply rules, and leave reviewable artifacts behind. That matters because a useful agent is not only something you talk to on demand. In many of these systems, agents can also schedule recurring tasks, check whether work has moved, prepare summaries, watch for changes, and push updates back to the team on a regular cadence. In practice that means an agent can send a morning status digest, monitor whether a release checklist was completed, compile competitor changes into a weekly brief, or remind a team when a workflow has stalled. The point is not just interaction. The point is operational follow-through. Communication surfaces matter too. Some agents live mainly in the terminal or desktop app, but the broader pattern is increasingly about agents that can meet the team where the work already happens. That may be team chat, issue trackers, email, or more private channels such as WhatsApp. Once an agent can receive instructions, ask follow-up questions, and report results in the same channels people already use, it starts to behave less like a novelty interface and more like an additional operating layer around the work. The constraint layer is usually text. Guard rails are often written as standing instructions, repo-level rules, folder-level instructions, task-specific prompts, skills, plugins, or runbooks. That sounds simple, but it is powerful because it is editable. When the agent behaves badly, you can tighten the rules. When the agent misses context, you can add it. When a workflow proves reliable, you can codify the pattern into a reusable skill. Over time, the quality of the system depends less on one brilliant prompt and more on whether the team keeps refining the written operating discipline around it. Some systems also let agents write down what they learn in files they can revisit later. That might be a project memory file, a scratchpad, a task log, a reusable checklist, or a repository instruction file. Used well, this turns repeated work into a compounding asset. The agent does not just complete a task. It leaves behind a better way to do the next one. Used badly, it can also create stale or contradictory instructions, which is why these learning files still need review, pruning, and ownership. That is also where the risks show up. A system with broad file access, shell access, internet access, or connector access can move from useful to dangerous very quickly if the surrounding controls are weak. Typical failure modes include editing the wrong files, making destructive changes too early, leaking sensitive data through tools or web access, automating brittle workflows that were never stable to begin with, or creating expensive loops where the team mistakes visible activity for genuine progress. The mitigations are not mysterious, but they do require discipline. Start with scoped permissions, narrow task boundaries, and explicit owners. Prefer read-only or workspace-limited modes first. Use sandboxing where the tool supports it. Add approvals before destructive actions, network access, or write paths outside the intended scope. Use skills, plugins, and runbooks so the system is not reinventing the workflow from scratch every time. Keep instructions close to the work. Add hooks, tests, validation steps, and human review at the points where mistakes would actually matter. And when you introduce recurring tasks or chat-connected agents, define what they are allowed to send, to whom, how often, and what should trigger escalation back to a human. This is where the positive case for moving now starts to matter. If you are willing to take a calculated risk, you do not have to wait years for a more polished generation of tools to arrive before you begin capturing value. You can start now with bounded workflows, sensible controls, and a codified operating surface, and benefit from faster learning, lower coordination cost, and earlier institutional experience while others are still waiting for maturity to arrive prepackaged. That is also why we keep returning to the logic in Why Code-Centric AI Workflows Will Outperform Traditional Business Tools . Codifying the business is not a detour. It is how teams get ahead of the curve. Once work lives in forms that agents can inspect, version, test, and improve, the current generation of tools becomes much more useful right away. The setup burden is real, but so is the advantage of building the operating discipline now instead of joining later when everyone has access to the same polished surface. If you want help deciding which entry point fits your team, start with our OpenClaw Setup service.


Title: You do not need artisanal websites anymore
URL: https://formationxyz.com/blog/you-do-not-need-artisanal-websites-anymore/
Published: 2026-03-19
Author: XYZ by FORMATION
Description: Most small teams no longer need slow, precious website projects. They need websites that can ship, learn, and improve at the speed of the business.
Body: There was a time when building a website felt like commissioning a bespoke object. Weeks of design rituals. Pixel debates. Long discussions about gradients, whitespace, hover states, and whether the button should feel a bit more premium. A small army of specialists hand-tuning every corner of the experience. That model is getting expensive in all the wrong ways. This is not because design stopped mattering. It did not. Brand still matters. Clear positioning still matters. Strong interfaces still matter. But the economics of production changed, and a lot of teams are still acting as if they did not. If your small team still treats website work as a slow craft process, there is a good chance you are overspending on the wrong part of the problem. Most companies do not need another precious website project. They need a website that can keep up with sales, answer questions, support campaigns, capture demand, and improve without turning every update into a mini production. That is where agentic workflows change the game. A modern website does not have to remain a static object that gets launched, neglected, and eventually redesigned. It can operate more like a live system. Content can be drafted, updated, localized, tested, expanded, and maintained continuously. Landing pages can be created around campaigns or search intent in hours instead of weeks. Messaging can evolve as the market evolves. SEO improvements no longer need to sit in a backlog for six months waiting for spare capacity. The problem is not taste. The problem is treating routine website operations like a museum craft. This is not about replacing taste with slop. It is about replacing unnecessary drag with a faster operating model. The old craft model made sense when production was slow, specialised, and expensive. Today, small teams can use AI systems and agentic methods to compress the path from idea to live page dramatically. That means more experiments, more iteration, more learning, and less ceremony. The website stops being a bottleneck and starts becoming useful again. That is the uncomfortable part for some people. A lot of web work was organised around scarcity. Scarcity of design skill. Scarcity of development skill. Scarcity of content production capacity. Scarcity of people who knew how to make the machine move. As that scarcity drops, some roles do not vanish, but they do change. The value shifts away from manually crafting every page and toward shaping systems that can produce, improve, and operate pages at scale. In other words, the winner is not the person polishing one perfect page for three weeks. The winner is the team that can publish ten good pages, learn from the market, improve the two that matter, and connect the whole thing to real business outcomes. For small teams, this shift matters even more. You do not have the luxury of slow handoffs and precious process. Your website has to help with growth, credibility, lead generation, positioning, recruiting, and customer education. It has to keep up. If every update requires scheduling, briefing, waiting, reviewing, revising, and relaunching, your website is not a business asset. It is operational drag. That is why we think the future is not shallow “AI-generated websites.” The future is agentic-ready websites: websites designed to evolve quickly, integrate with workflows, support automation, and improve continuously with less manual effort. That is also the logic behind our Promptable Website , Agentic Webmaster , and existing website migration work. The point is not to make the website look automated. The point is to make the website operationally responsive. This shift also connects directly to the broader acceleration pattern we described in What if time to market was measured in hours or days instead of months or years? . When the cost of changing pages, offers, and funnels drops, more ideas survive long enough to meet the market. And when the website itself is treated like a structured operating surface, the pattern starts to resemble the code-centric AI workflows we keep returning to: versioned assets, faster iteration, clearer review paths, and a system that gets easier to improve over time. The point is not to eliminate humans. The point is to stop wasting human attention on work that no longer needs to be slow. Good taste still matters. Clear thinking still matters. Strong positioning still matters. But the age of treating routine website work like it requires artisanal devotion is ending. For most companies, that is good news. It means lower cost, faster iteration, and more leverage. And yes, somewhere, a monocled CSS purist is standing in the rain mourning the loss of handcrafted button shadows. Meanwhile, the teams that embrace agentic workflows are shipping. If your website still moves at the speed of a design committee, it is probably time to change the operating model around it. If you want to compare the practical entry points, start with our services overview or talk to us about where the drag is really coming from.


Title: Why Code-Centric AI Workflows Will Outperform Traditional Business Tools
URL: https://formationxyz.com/blog/code-centric-ai-workflows/
Published: 2026-03-18
Author: XYZ by FORMATION
Description: Teams that move core business workflows into code-centric tools gain a practical advantage with AI: more consistency, faster iteration, better reuse, and a path toward deeper tool integration without requiring non-developers to write code.
Body: Most companies still try to apply AI on top of tools and workflows that were never designed to be steered programmatically. They add a chatbot to a document process, or a prompt box to a content tool, and hope that this counts as transformation. Usually it does not. The real shift happens when the workflow itself moves into an environment where AI can inspect files, follow structure, apply rules, reuse assets, and make changes in a controlled way. That is why code-centric workflows matter. This does not mean everyone in the business needs to become a software engineer. It means the work happens in systems that are easy to script, easy to version, and easy to operate with precision. Developer tooling has had those properties for a long time. Repositories, markdown, structured config, build pipelines, asset folders, scripts, validation checks, and deployment steps are all things an AI can already work with surprisingly well. Developers are ahead of the curve here for a simple reason: their tools are already compatible with automation. A source repository is not only readable to a human team. It is also actionable for an AI. The model can inspect the current state, compare alternatives, generate or edit files, run checks, and refine the result in a loop. That is much harder in many traditional business tools, where the work sits behind a visual interface, opaque storage, or awkward export formats that are difficult to automate cleanly. The advantage is not limited to software products. Presentations, websites, sales collateral, internal documentation, operational playbooks, and campaign assets all become more manageable when they are treated as structured project artifacts rather than isolated files living in disconnected SaaS interfaces. Once that happens, AI can do more than write a first draft. It can maintain consistency, update old assets, reuse working patterns, and build new outputs on top of previous ones. That consistency is often underestimated. In a code-centric workflow, you can keep visual systems, naming conventions, tone of voice, approved language, shared components, and reusable building blocks in one place. Over time, every new output starts from the last good version rather than from a blank page. This applies to decks, but also to service pages, product briefs, onboarding flows, internal agents, and operating procedures. The result is not just speed. It is operational continuity. It also changes how iteration works. If a team does not like a result, they do not need to restart manually. They can point the AI at the current artifact, provide screenshots, comments, source material, or examples of what should change, and let it revise the existing system. That is a much better feedback loop than repeatedly asking for brand-new outputs with no memory of what came before. This is one reason we think business workflows should increasingly be redesigned on top of developer tooling. Developer tools are already close to where AI wants to be: scriptable, modular, inspectable, testable, and composable. They are built for precision and repeatability. Those same properties make them good substrates for AI operations. What looks like a developer preference today is likely to become a broader business advantage over the next few years. The important part is that non-developers do not need to write code themselves to benefit. If the AI is doing the heavy lifting, the interface for the team can remain much simpler: goals, feedback, assets, constraints, approvals, and review. Underneath that, the system can still use repositories, scripts, structured content, and deployment workflows. The value comes from the architecture of the workflow, not from forcing everyone to become technical. At FORMATION, we care about this because we have been building and shipping products across several waves of technology change, from before the dot-com bubble to now. That gives us a long view on what is hype, what is infrastructure, and what actually compounds. Our current view is that teams will get more leverage from bending AI into disciplined workflows than from collecting disconnected AI features with no operational backbone. This is also why FORMATION talks so much about practical systems. We are not interested in AI as theatre. We are interested in how to make it useful in daily operations, content systems, product development, and decision support. A code-centric workflow is one of the strongest foundations for that because it lets AI work inside environments where quality can be checked, structure can be preserved, and outputs can be improved over time. If your team is still treating AI as something that sits beside the workflow, the next step may be to redesign the workflow itself. Interested in rethinking business workflows on top of developer tooling so AI can do more of the work for you? Talk to us .


Title: How AI Can Pull Development and Operations Teams Out of DevOps Hell
URL: https://formationxyz.com/blog/how-ai-can-pull-dev-and-ops-teams-out-of-devops-hell/
Published: 2026-03-18
Author: XYZ by FORMATION
Description: AI coding agents can remove a large share of painful infrastructure and deployment work, but the real advantage comes when development and operations teams learn how to use them with guardrails, review habits, and operational discipline.
Body: This article is based on Escaping DevOps hell with Codex , an article by our CTO Jilles van Gurp. Development teams rarely get blocked by the big idea. They get blocked by the ugly operational detail wrapped around it. A feature is ready, a migration needs to happen, a cluster needs to be upgraded, or a deployment setup needs to be cleaned up. Suddenly the team is no longer building product. It is spending days in shell sessions, YAML, networking rules, permissions, bastion hosts, and configuration drift. That is why DevOps so often feels disproportionate to the business outcome. The original task may be straightforward: move this system, deploy that service, tighten this rollout, reduce hosting cost, make the environment safer. But every operational step sits near failure modes that matter: downtime, security mistakes, bad backups, partial rollouts, silent misconfiguration, or data loss. Even experienced technical people can lose large amounts of time in this layer. AI changes that, but not in the simplistic way many people assume. The useful pattern is not to hand infrastructure to a chatbot and hope for the best. The useful pattern is to let an AI coding agent work inside a structured environment where it can inspect repositories, understand scripts, edit configuration, run checks, compare results, and document what it learned. In that setup, the agent becomes a practical execution layer for work that used to consume senior attention. This is particularly effective in development and operations because the work already lives in machine-readable systems. Repositories, infrastructure code, Ansible, Docker, CI scripts, deployment configs, runbooks, and validation steps are all things an AI can operate on directly. That matters. A good AI workflow is much easier to build when the work itself is already structured, versioned, and testable. The catch is that this still needs experienced judgment. The difference between a productive AI-supported migration and a dangerous one is usually not model capability alone. It is workflow design. Somebody needs to define what success looks like, what preflight checks happen first, what approvals are required, what should trigger rollback, and what evidence counts as safe enough to continue. That is where operational maturity still matters. The teams getting real value from AI in this area are not the ones treating it like a magic answer box. They are the ones turning experience into reusable operating patterns. When a rollout works, they capture the steps. When a failure happens, they improve the instructions and the checks. When the AI learns a reliable fix, they turn that into a repeatable skill or runbook. Over time, the team is no longer starting from scratch on every messy operational task. That same pattern also sits behind our broader view on code-centric AI workflows , where structured tools and repositories give AI much more room to operate safely and usefully. This is one reason we think coaching matters more than tool access. Most teams can already open an AI product and ask it for help. That is not the hard part. The hard part is teaching development and operations teams how to work with AI in a disciplined way: how to break work into safe steps, how to review outputs, how to keep logs and reports useful, how to build confirmation gates, and how to decide what should remain human-controlled. That operating shift is closely related to what we described in How AI Will Create New Departments Inside Small Companies : the value comes when AI becomes part of the working system, not just an assistant sitting beside it. Once those habits are in place, the payoff can be substantial. Infrastructure migrations compress. Configuration cleanup gets easier. Repetitive diagnostics become faster. Rollouts become more deliberate instead of more manual. Teams spend less energy on ritualistic troubleshooting and more energy on architecture, delivery, and customer-facing work. That does not eliminate operations work, but it changes the cost structure of doing it well. For smaller companies, this matters even more. Many do not have a dedicated DevOps team. The burden lands on a CTO, senior developer, platform lead, or whoever is currently least busy, which usually means nobody. AI can give that team more operational reach, but only if the way of working improves with it. Otherwise the company just automates confusion. And once those ways of working are in place, they often contribute to the wider acceleration effect we described in What if time to market was measured in hours or days instead of months or years? . The practical opportunity is not to replace your development and operations teams. It is to upgrade how they operate. If your developers and operators are capable but still spending too much time in avoidable infrastructure pain, we can help coach the team on agentic ways of working, introduce the right guardrails, and turn repeated DevOps work into safer AI-supported workflows. A good place to start is our Engineering Team Agentic Setup , or simply talk to us if you want to work through your current bottlenecks.


Title: Inside the very small but very clever Help Chatbot on the XYZ Website
URL: https://formationxyz.com/blog/inside-the-robot-on-our-website/
Published: 2026-03-18
Author: XYZ by FORMATION
Description: Our site robot is intentionally not powered by live LLM calls yet. Instead, it combines an AI-assisted internal FAQ, rule-based retrieval, careful caching, and privacy-aware analytics to guide visitors through the site.
Body: There is a small robot in the corner of this website. It is there to answer questions, point people to the right page, help qualify what they are looking for, and occasionally nudge a promising conversation toward contact. Because this site is about AI and agentic systems, one obvious question follows quickly: why is that robot not simply a live LLM chatbot? The short answer is that we chose not to do that yet. The longer answer is more interesting. We are using our own agentic webmaster as a guard rail around the site, and part of that workflow is to inject content specifically for the bot. We want the robot to know the services, ideas, FAQs, blog posts, and navigation paths of this site in a structured way. We want it to be useful. But we also want it to stay fast, cheap to run, easy to reason about, and simple to maintain. That trade-off led us somewhere we actually like quite a lot: a modern site bot with a slightly old-school soul. Before large language models, there were text adventures, MUDs, parser-driven role playing games, and a whole class of systems that felt alive because the rules were clever, the content was well prepared, and the interaction design respected the imagination of the player. Many of us who have been building software since the last century still have a deep fondness for those systems. They did not pretend to understand everything. They only had to understand enough, in the right way, to make the interaction feel rewarding. That is very close to what this robot does. At runtime, the bot is deliberately simple. It searches a prepared knowledge layer, matches what you asked against site content, ranks likely answers, and responds with relevant links, suggestions, and next steps. There is no live model call behind every message. No token meter spinning in the background for routine site questions. No extra moving parts just to answer something that the website already knows. The important point is that simple does not mean dumb. We still use AI where it pays off. We use it upstream. As part of the site update process, we maintain an internal FAQ layer with generated question-answer pairs derived from our pages, blog posts, services, and curated chat overrides. In other words, we prepare the knowledge before the visitor arrives. We can shape likely questions, tighten answers, add follow-up prompts, and connect each answer to the right pages. Some of that structure is generated automatically from content. Some of it is refined through our skill-driven workflow. And yes, some of the rules and patterns behind it were created with AI as well. We are not anti-LLM. We are simply using LLMs where they create leverage instead of cost. This is why we say the robot is not using LLMs yet, but the system around it absolutely benefits from them. The intelligence is front-loaded into the content pipeline. The runtime stays deterministic. That architecture has a few practical advantages. First, it keeps response times snappy. Second, it avoids paying model costs for every visitor interaction. Third, it reduces operational complexity because the behavior is easier to test, inspect, and tune. If a page changes, our update process can regenerate the hidden chat knowledge, keep the bot aligned with the latest content, and avoid turning the website into a fragile demo. We also gave ourselves a small engineering gift: a caching hack that skips regeneration work when content has not changed. The bot knowledge builder hashes source pages and reuses cached entries for unchanged material. That means the skill-driven update flow stays efficient even as the site grows. Years of articles, service pages, press releases, deep pages, and FAQs do not need to be reprocessed from scratch every time. The system only refreshes what actually moved. This becomes especially useful once a website has real history. Most companies are sitting on far more content than they actively use: old blog posts, announcements, campaign pages, case studies, long-form product explanations, and niche FAQ material that still contains valuable answers. A tailored site bot can unlock all of that. It can surface relevant material faster, drive deeper engagement, run lightweight surveys to sharpen intent, and help route people toward the right offer or conversation without making them hunt through navigation menus. On this site, that layer goes beyond simple retrieval. The robot can also gather a few structured details, help a visitor clarify what they need, and move toward a cleaner handoff. This is where the old text-adventure influence becomes especially fun. Good guided conversation is not only about free-form language. It is about pacing, hints, branching, and knowing when to offer the next meaningful move. Then there is the analytics side, which matters just as much as the conversation itself. Our bot is deeply integrated with our own analytics platform. When a visitor has explicitly accepted optional cookies, we can analyze questions, responses, navigation paths, and conversation patterns inside our self-hosted environment. That helps us understand what people are looking for, which parts of the site are doing real work, which topics create friction, and where the content itself should improve. This is useful for more than bot tuning. It tells us what the audience cares about, what kinds of visitors are arriving, which questions keep repeating, and where there may be unmet demand. That can inform content strategy, page structure, offer design, and future experiments. In other words, the robot is not only a helper for visitors. It is also an instrument for learning. The important boundary is privacy. We are not interested in creepy surveillance theatre. We are respecting GDPR, using consent properly, and keeping these conversations inside our self-hosted stack rather than spraying them across a chain of third-party services. The point is to learn enough to improve the site and the experience, not to build an ad-tech monster. Over time, we may decide that a live LLM belongs in this loop. There are cases where it clearly would. But for this stage of the project, the more elegant answer was to do the simpler thing well. A prepared knowledge layer. Smart rules. Skill-driven updates. Efficient caching. Good analytics. Strong guard rails. Sometimes a bit of clever coding is all you need. And if you like this pattern, we can help you build one too. We can tailor a similar bot to your website, connect it to your content base, shape the internal FAQ, align it with your tone and offers, and feed the resulting learnings back into your site operations. If your company is sitting on years of useful material that people rarely find, this is one of the cleanest ways to make that knowledge work again. Curious how this feels in practice? Try the robot on this site and see where it takes you.


Title: How We Used AI to Build a GeoIT Symposium Presentation Fast
URL: https://formationxyz.com/blog/geoit-symposium-ai-presentation/
Published: 2026-03-18
Author: XYZ by FORMATION
Description: For our 16 March 2026 GeoIT Symposium talk, we used AI to generate a polished Reveal.js presentation, shaped it with repo-specific skills, improvised a PDF export skill, and published the deck on Cloudflare Pages.
Body: We recently presented at the GeoIT Symposium in Berlin on 16 March 2026 with a talk about Open RTLS, indoor mapping, and the practical layers missing from many location-system stacks. The live presentation is public at open-rtls-geoit.pages.dev , and the source for it is in the public Open-RTLS GeoIT Symposium repository . What matters to us is not just that we gave the talk. It is how we produced it. Instead of building the deck slide by slide by hand, we used AI to generate a sophisticated Reveal.js presentation with a clear story, strong pacing, and a slick design language that matched the subject matter. The result felt much closer to a small product launch than to a traditional last-minute slide deck. The final deck looked more like a small product launch than a rushed set of conference slides. Because the deck lived in a repo instead of in a slide editor, the AI could work on real project artifacts: slides.md, the presentation CSS, SVG visuals, screenshots, deployment config, and support scripts. That changes the quality of what you can get. You are no longer asking an assistant to guess what good slides might look like. You are giving it a structured workspace where it can actually build and refine the presentation as a working system. The design quality came from that setup. The deck was built in Reveal.js, styled as a lightweight branded site, and published to Cloudflare Pages. That meant we could iterate quickly on layout, hierarchy, images, QR codes, and pacing, while still keeping the output easy to host, easy to share, and easy to version. Public delivery matters here, because a presentation should not disappear after the room empties. It should become a reusable asset. The other important part was skills. We used repo-local skills to control what the AI was allowed and expected to do. For example, the deck maintenance skill told the model which files mattered, which narrative to preserve, what visual direction to keep, and what not to overcomplicate. That sounds simple, but it is a big operational difference. Without skills, you get a capable model with a lot of freedom. With skills, you get a more disciplined collaborator that understands the intended workflow and stays inside the rails. In practice, that meant the AI could help with presentation writing without drifting into generic filler. It knew the deck should stay mapping-first, keep the Open RTLS story concise, avoid unnecessary runtime complexity, and preserve the established visual language. The same mechanism is useful well beyond presentations. Skills are one of the cleanest ways to turn an AI from a broad assistant into a reusable team process. One detail we particularly liked was how we handled PDF export. Reveal.js has print options, but they do not always preserve the exact on-screen result, especially when you have runtime fitting, layout tuning, and slide-level polish that is designed for the viewport. So we improvised a separate export skill for PDF generation. Instead of relying on print mode, the skill starts a local preview server, opens the deck in a headless browser, captures each slide as a screenshot, and then stitches those screenshots into a one-page-per-slide PDF. That is a practical engineering workaround, and it is exactly the kind of small but high-leverage tool AI is good at helping create. This is the broader point. AI is not only useful for writing text inside slides. It is useful for building the whole presentation pipeline: structure, copy, design, visuals, deployment, and export. Once the work happens in a repo with the right constraints, creating a high-quality presentation becomes much closer to shipping software than dragging boxes around in a presentation tool. There is also a compounding effect. Once presentation work moves into a workflow like this, you can steadily enforce consistent visuals, consistent language, and reusable structure across decks. Each new presentation can start from the patterns, components, and phrasing that already worked in earlier ones. And if a deck needs refinement, you can iterate in a very direct way: give the AI screenshots of the current version and explain what feels off, or provide screenshots of source material you want it to work from. That turns presentation design into an iterative operating process instead of a fresh manual effort every time. If that sounds appealing, explore the live deck at open-rtls-geoit.pages.dev and the source repo at github.com/Open-RTLS/geoit-symposium-march26 . Interested in using AI to never make presentations manually again? Talk to us .


Title: What if time to market was measured in hours or days instead of months or years?
URL: https://formationxyz.com/blog/time-to-market-hours-not-months/
Published: 2026-03-16
Author: XYZ by FORMATION
Description: Agentic workflows and newer tools are shrinking the path from idea to launched service, making faster testing, validation, and iteration commercially realistic for small teams.
Body: What happens when time to market stops being measured in quarters and starts being measured in hours? That is one of the most important shifts hiding inside agentic workflows, better orchestration, and the newer layer of tools now arriving across design, development, operations, and distribution. The old path from idea to launched service was full of waiting: waiting for briefs, waiting for build cycles, waiting for design rounds, waiting for handoffs, waiting for internal alignment, waiting for some future moment when the concept felt finished enough to show to the market. That path is breaking down. A strong founder or operator can now go from rough concept to landing page, offer framing, intake flow, operating logic, basic automation, and first customer outreach in a matter of hours or days. Not because the work has become trivial, and not because quality no longer matters. It is because the cost of moving from thought to first working version has dropped sharply when the team knows how to use agentic systems as part of the operating method. This matters because the first version of a service usually should not be treated like a permanent artifact. It should be treated like a live market probe. A service page can become a test. A positioning angle can become a test. A workflow can become a test. Pricing language, onboarding steps, outbound copy, qualification logic, and follow-up sequences can all be tested quickly enough that the company starts learning in real commercial time instead of strategic imagination. When the launch path gets shorter, the market starts shaping the service much earlier. That creates a new class of idea testing that did not really exist before in this form. Historically, many ideas died in the gap between being interesting and being operationally worth building. The friction was too high. The tooling was too slow. The budget threshold was too heavy. Now a founder can put an idea under pressure almost immediately. Does the market understand the promise? Do people click? Do they book? Do they reply? Do they ask sharper questions? Do they pay? That feedback loop can start while the idea is still warm. This is also why every web page can start behaving more like an A/B test. Not in the shallow sense of just swapping button colors, but in the more meaningful sense that every page can become a compact hypothesis about demand. Who is this for? What problem is urgent enough to act on? What language increases trust? What offer format creates motion? Once the page, funnel, and follow-up layer become easier to modify, the website stops being a brochure and becomes an active learning surface. That changes product iteration too. A service no longer needs to emerge fully formed before it meets the market. It can tighten through contact. You launch a narrow version, observe behavior, refine the promise, restructure the process, sharpen the interface, adjust the pricing, and improve the handoff. Then you repeat. The important thing is not speed by itself. It is speed connected to signal. The teams that benefit most will be the ones that turn fast execution into better judgment, not just more activity. There is a broader consequence here. If more entrepreneurs can move from concept to live service in days instead of months, then the number of experiments the market can absorb rises dramatically. More services get tested. More niches get explored. More weird combinations get tried. More operational problems get turned into products. A large share will still fail, as they should. But the cost of learning falls, and that means the rate of useful variation rises. That starts to look like a Cambrian explosion of service and software innovation. Not because every launch wins, but because the environment becomes much more favorable to rapid mutation, selection, and refinement. Good ideas no longer need to wait for large budgets, formal teams, or long development cycles before they can meet reality. They can be launched, judged, improved, and relaunched while the opportunity is still alive. The practical question is whether a team is set up to work this way. Fast time to market is not just about having access to tools. It depends on workflow design, prompt discipline, operating judgment, and a willingness to treat the first version as a test instead of a monument. Teams that build that capability will not just move faster. They will learn faster, and that may be the more important advantage. If you could launch and test a new service idea by tomorrow evening, what would you put in front of the market first?


Title: How AI Will Create New Departments Inside Small Companies
URL: https://formationxyz.com/blog/ai-departments-for-small-companies/
Published: 2026-03-16
Author: XYZ by FORMATION
Description: Small companies will not just buy AI tools. They will gain entirely new operating capacity as AI takes on real departmental work across finance, planning, procurement, and administration.
Body: One of the biggest misunderstandings around AI in small companies is that people still talk about it as if it were only a helper sitting beside the team. In practice, the more important shift is that AI can become a real operating layer inside the business. It can take on recurring work with enough consistency and speed that it starts to resemble a department, not just a feature. That matters because many small companies do not have the headcount to build every function they need. They still need someone to help with accounts, procurement, planning, compliance, scheduling, insurance paperwork, reporting, quote preparation, and endless administrative follow-through. Traditionally, that either lands on a founder, gets spread thinly across the team, or never gets done as well as it should. Software is also becoming much faster to make and much cheaper to make. That changes the economics for smaller firms. Functions that once looked out of reach because they needed too much custom software, too much overhead, or too many internal hires can now be assembled and improved much more quickly than before. AI changes that equation when it is applied properly. Not as vaporware, not as a novelty chatbot, and not as a demo that only works in ideal conditions. We are talking about systems that can read incoming information, route tasks, prepare drafts, check documents, update records, flag exceptions, and keep work moving across ordinary business processes that consume real time every week. In that sense, new departments can emerge without a company hiring a full department on day one. A small business might end up with an AI-supported finance function that chases invoices, organises records, prepares summaries, and keeps the books cleaner for human review. It might have an AI-supported operations function that plans jobs, coordinates equipment needs, handles ordering steps, and keeps project details from falling through the cracks. The useful version of AI is the one that carries real administrative and operational load inside the company. This also opens the door to more autonomous public-facing and regulatory work. Small companies regularly lose time dealing with forms, government interactions, insurance administration, supplier coordination, and the back-and-forth that sits around every practical decision. AI can become the first handler for that burden, turning scattered obligations into a more managed and trackable stream of work. That is the type of operational capacity we are aiming at with OpenClaw and our recurring SEO Manager service, where the system keeps working between human reviews. It also changes the threshold for what counts as a viable company. If software is cheaper to produce, and if more operational work can be handled by AI departments inside the business, then a company may not need the same revenue base or the same staffing model to be healthy. A small firm with one founder, or two people, may be able to operate with more stability, better service, and better margins than older assumptions would have allowed. That matters for lifestyle businesses as much as for venture-scale companies. Not every successful business needs to chase a giant team, a huge burn rate, or a narrow definition of hypergrowth. In many cases, a durable company that serves customers well, produces dependable profit, and gives its owners a good living is already a very good outcome. AI may widen the set of businesses that can work on those terms. What makes this valuable is not the theatre of sounding advanced. It is the fact that this is real labor. The work still exists. Someone or something has to do it. If AI can reliably absorb a meaningful portion of that burden, the business gains capacity it could not previously afford, and the human team gets to spend more time on customers, judgment, delivery, and growth. The important design question is where autonomy is appropriate and where oversight still belongs. Small companies will benefit most when they treat AI departments as managed operating units with permissions, escalation rules, and clear ownership. That is how you get practical leverage instead of chaos disguised as innovation. Teams that are still defining those boundaries usually benefit from a Deep Dive before they jump into implementation. My positive view is that this could make small-company economics healthier and more plural. More people may be able to run practical, independent businesses without needing to scale in the old way just to survive. The negative view is that bad implementation could still create brittle operations, hidden errors, and false confidence if owners treat automation as magic instead of managed infrastructure. The companies that move earliest here will not look bigger because they hired faster. They will look bigger because they operate with more administrative muscle, more follow-through, and more day-to-day execution capacity than their headcount would normally allow. If AI gave your company one new department this year, which one would create the most real value first, and do you see that as a positive shift or a worrying one?


Title: How Agentic Workflows Will Transform Small Businesses
URL: https://formationxyz.com/blog/german-small-business-agentic-workflows/
Published: 2026-03-15
Author: XYZ by FORMATION
Description: German small businesses do not need science fiction. They need practical semi-autonomous workflows that remove drag without adding more systems overhead.
Body: For many small businesses in Germany, the case for agentic workflows is not about replacing teams. It is about giving lean teams more leverage at a moment when cost pressure, slower demand, and hiring constraints are all colliding. Recent German business surveys still show cautious investment sentiment, which makes practical productivity gains more relevant than grand transformation theatre. When you look at a diffraction pattern, the interesting part is not the beam itself but what becomes visible once light passes through a real surface. Operational bottlenecks work in a similar way. They reveal themselves when a company grows, when demand shifts, or when a small team has to keep too many moving parts aligned with too little slack. That is where semi-autonomous workflows start to matter. A well-scoped system can draft customer replies, triage inbound requests, prepare sales research, move information between tools, or flag issues before a human has to chase them manually. The point is not to hand the company to a robot. The point is to stop spending skilled time on repetitive coordination work that should have disappeared already. For a small business, this can affect nearly every function that suffers from stop-start momentum. Sales teams lose time preparing context before calls. Operations teams re-enter the same data into multiple tools. Founders become manual routers of information because no one else has the full picture. Agentic workflows do not solve strategy by themselves, but they can refract work into clearer streams so the next action becomes easier to see. The useful shift is not more tooling by itself. It is clearer workflow orchestration that gives a small team more leverage. Autonomous workflows become interesting when the rules are clear and the downside of speed is low. Internal reporting, lead qualification, document routing, knowledge retrieval, QA preparation, and routine follow-up are all good candidates because they benefit from consistency and fast iteration. In a small company, every hour recovered in these areas can be reinvested into customers, delivery, and commercial momentum. That is exactly the kind of practical operating layer we build through OpenClaw and more tailored Promptable Website work. Germany is an especially useful context for this shift because many companies operate with strong process discipline already, even when the tooling layer is fragmented. That makes the opportunity less about importing chaos in a newer form and more about upgrading established routines with better orchestration, faster response times, and less manual handoff work. The best outcomes usually come from improving a real business process that already matters, not from launching a disconnected AI side project. The constraint is not the model. It is operational design. Small teams need workflows with clear permissions, fallback paths, logging, and owners who understand where human review still belongs. The companies that benefit most will be the ones that treat agentic systems as operating infrastructure, not as a novelty layer bolted onto an already messy process. For teams that need to map the process before they automate it, our Deep Dive and Competitive Landscape offers are designed to make those decisions more concrete. That is why the conversation should start with friction, not fascination. Where is time leaking out? Which workflow creates avoidable delay? Where do skilled people spend their day acting as glue between systems that should already talk to each other? Once those questions are answered honestly, the light gets sharper and the implementation path usually becomes more obvious. If your business in Germany could remove one daily bottleneck this quarter, which workflow would you trust enough to let a capable agent handle first?


Title: Getting Good Ideas Unstuck
URL: https://formationxyz.com/blog/ideas-in-motion/
Published: 2026-03-12
Author: XYZ by FORMATION
Description: Ideas in Motion is our way of helping founders and operators move promising concepts out of limbo and into something testable, operational, and real.
Body: Most ideas do not fail because they are impossible. They stall because nobody creates enough structure around them soon enough. The gap between a strong hunch and a real business concept is usually filled with unanswered operational questions: who it serves, what system supports it, how it gets tested, and what shape the first useful version should take. Ideas in Motion exists because that in-between state deserves more respect. It is easy to dismiss an unfinished concept as vague. In practice, that early stage is often where the strongest commercial signals first appear, only in diffuse form. The job is not to wait for perfect clarity. The job is to refract that signal until the meaningful lines start to separate from the noise. That is the space Ideas in Motion is built for. We are offering founders and operators a way to accelerate concepts that are still half-formed but commercially interesting. Instead of waiting for a perfect spec, we help turn the raw signal into a sharper problem definition, a clearer operating model, and an execution path that can actually be tested. The six ideas already on the site show the range we mean. Company Cockpit asks how a small company could run from one practical decision layer. Optical Asset Tracking explores whether cameras and software can replace more expensive tracking overhead. QR Luggage Tags, Tee Me, Timeless Prints, and Your Idea? all point to the same belief: useful ventures often begin as operationally messy fragments, not polished decks. A good early idea becomes more interesting once it can be seen in a concrete operational setting. What joins these examples is not sector. It is momentum. Each one carries a practical tension that could become something bigger with the right pressure, whether that means a research spike, a prototype, a service-backed pilot, or a partner conversation that sharpens the commercial path. We like this territory because it sits between consulting and venture building. Sometimes the right next step is a short research spike. Sometimes it is a prototype, a workflow experiment, a partner conversation, or a new service line hiding inside a rough concept. The value comes from moving the idea forward with enough pressure that its real shape starts to reveal itself. In practice, that often starts with a Deep Dive , a Roadmap Audit , or a more hands-on Engineering Upgrade . That is also why the work cannot stay theoretical. A concept becomes more useful once it meets operational reality: delivery constraints, customer expectations, system design, pricing logic, implementation friction, and the many small details that either bend an idea into shape or reveal that it needs to change. Movement is the filter. When that happens well, the founder or team does not just leave with a nicer story. They leave with a better sense of what to test next, what to ignore, where the signal is strongest, and what version of the idea might actually deserve committed resources. If you want to compare those entry points directly, the services page lays them out side by side. Which idea in your business keeps resurfacing because it deserves motion, not another month in a notes app?


Title: Why We Created XYZ
URL: https://formationxyz.com/blog/why-formation-launched-xyz/
Published: 2026-03-09
Author: XYZ by FORMATION
Description: XYZ exists because FORMATION chose to test agentic operations on itself first, then package the patterns that proved useful into services for other teams.
Body: XYZ did not start as a brand exercise. It started because we were already changing how FORMATION operates internally and saw that the results were too useful to keep as an internal advantage. We streamlined recurring operational work, tightened delivery loops, and pushed more of our development process into faster agentic patterns that let a small team move with more force. In that sense, XYZ came out of refraction. Once these newer tools passed through the real surface of delivery work, internal ops, and team coordination, the pattern became easier to read. Some workflows accelerated immediately. Some looked impressive at first and then broke under normal operating pressure. Some needed more human judgment than the software-first narrative would suggest. That matters because a lot of companies are experimenting right now, but fewer are truly reorganising around these newer ways of working. Many teams are trying prompts, scattered tools, and one-off automations. Far fewer are committing to the more uncomfortable part: redesigning workflows, habits, and accountability so that agentic systems become part of how the company actually runs. We decided to be our own test case. That means we take the friction first, find the parts that break, learn where oversight still matters, and build a more honest view of what works in day-to-day operations. In other words, we are willing to guinea pig ourselves before asking a client to trust the outcome. XYZ came out of hands-on operational change inside FORMATION, with the team itself acting as the first proving ground. That choice shaped the service model. We did not want to offer vague AI enthusiasm. We wanted to offer practical entry points built from what had already held up under real use: OpenClaw setups for teams that need a broader operating layer fast, engineering upgrades for teams that want better delivery leverage, deep dives for organisations ready to change how the work flows, and roadmap audits for leaders trying to see further ahead. The Berlin focus is deliberate too. A lot of this work is not just technical implementation. It is change management, workflow design, trust-building, and live iteration with people who still need to ship, sell, and support customers while the system underneath them evolves. Proximity makes that easier, especially when the point is to improve real execution rather than stage a future-facing demo. There is also a broader motivation behind XYZ. The pace of innovation in agentic systems is unusually high right now, and the gap between what is newly possible and what most companies are actually doing remains wide. We think there is room for a partner that does not just comment on that gap but works inside it, tests it, and turns usable patterns into something other teams can adopt. XYZ is how those learnings leave the building. It is our way of packaging what has survived contact with reality and making it available to other companies as a practical service instead of a private advantage. If your team is deciding where to begin, our service overview is the clearest place to compare the entry points. If your team had a partner willing to absorb the experimentation risk first, what would you want to accelerate right now?

## MVPs
Title: Optical Asset Tracking
URL: https://formationxyz.com/mvps/vision-based-asset-tracking/
Description: A vision-based venture concept for tracking physical assets with cameras, software, and practical operational workflows.
Body: Optical Asset Tracking is an idea in motion around a simple question: can high-value equipment, containers, tools, or stock be tracked reliably with cameras and software instead of expensive dedicated hardware on every item? The concept uses computer vision to recognise assets, locations, movements, and handoffs in the real world, giving operators a clearer picture of where things are and what is happening around them. For XYZ, a division of Formation GmbH, this sits in the space between applied research and venture building. In some cases it may be developed directly by XYZ. In other cases it may move forward with logistics operators, industrial partners, software teams, or specialist researchers who bring domain expertise in machine vision, sensing, or operations. The opportunity is not just technical. A good optical asset tracking system could reduce manual scanning, improve inventory confidence, shorten search times, and make operational bottlenecks more visible. That makes it a strong candidate for a new product line, a joint venture, or a spin-out business if the problem, market, and implementation path prove compelling. Some of this work may begin as a research spike: a focused effort to test feasibility, map edge cases, and understand where vision-based tracking is operationally strong enough to become a real business. If you have a venture you want to take forward in this area, please contact us. We are always willing to talk. If you want the broader context for how we pressure-test ideas like this, start with Getting Good Ideas Unstuck . If you want to move from concept to a more concrete working shape, compare a Deep Dive with a Roadmap Audit .


Title: QR Luggage Tags
URL: https://formationxyz.com/mvps/qr-baggage-tags/
Description: A venture concept for simple, scannable luggage tags that could improve how baggage is tracked across travel networks.
Body: QR Luggage Tags is an idea in motion built around a practical premise: baggage tracking should be easier, cheaper, and more transparent for travellers and operators. The concept explores whether robust QR-based tags, paired with the right software and operational processes, could create a more accessible tracking layer for airline luggage, rail luggage, and other bags moving through complex transit systems. For XYZ, a division of Formation GmbH, this is the kind of venture that may be pursued independently or with partners across mobility, travel, logistics, insurance, or infrastructure. The ambition is not just a tag itself, but a whole service model around identity, scan events, passenger visibility, operator workflows, and exception handling when bags are delayed, rerouted, or lost. This is also the sort of concept that benefits from research spikes and early pilots. We may work with specialist researchers, transport operators, hardware partners, or product teams to test usability, durability, adoption barriers, and commercial fit. If the results are strong, the idea could evolve into a dedicated venture or spin-out business in its own right. If you have a venture in travel, luggage, mobility, or tracking that you want to take forward, please contact us. We are always willing to talk. For the broader venture logic behind concepts like this, read Getting Good Ideas Unstuck . If you want a practical entry point, a Deep Dive or Roadmap Audit is usually where this kind of idea starts to become more concrete.


Title: Company Cockpit
URL: https://formationxyz.com/mvps/cockpit/
Description: A venture concept for Harmonitor, a single operating view that helps founders and teams run a company with less fragmentation.
Body: Company Cockpit is an idea in motion built around Harmonitor, a simpler way to run a business. Many founders and small leadership teams work across disconnected tools for finance, delivery, hiring, sales, compliance, planning, and reporting. Harmonitor is the core concept: a single company view that pulls the most important signals together so decision-makers can see what matters, where attention is needed, and what should happen next. For XYZ, a division of Formation GmbH, Harmonitor could become a standalone venture, a partner-led product, or a targeted research and design programme to validate what a useful operational cockpit should really be. The idea is not to make yet another dashboard. It is to create a practical decision layer that helps companies act with more confidence and less noise. There is room here for specialist input from researchers, operators, finance experts, workflow designers, and software partners. Some versions may stay as internal venture exploration. Others may mature into spin-out businesses if the problem definition, product shape, and market pull line up. If you are working on founder tools, company operations, or decision systems and want to shape Harmonitor further, please contact us. We are always willing to talk. For related thinking, see How AI Will Create New Departments Inside Small Companies and Getting Good Ideas Unstuck . If you want to compare practical ways to explore something like Harmonitor, start with a Roadmap Audit or Deep Dive .


Title: Tee Me
URL: https://formationxyz.com/mvps/tee-me/
Description: A venture concept for a simple way to order a t-shirt and have it delivered to you haste, post, haste
Body: Tee Me is an idea in motion for a simple way to order a t-shirt, built on Formation. The goal is a clean ordering flow where the customer places the order once and the operational handoffs happen through the system instead of through manual back-and-forth. You can see the live MVP at teemynow.com . When the t-shirt is ordered, the order is relayed to the print service. When the shirt is ready, a Formation route to the customer is sent to the delivery partner so the next step is clear and operationally simple. The concept is intentionally lightweight: straightforward product selection, a practical Formation-backed workflow, and clear handoffs from order to print to delivery. It does not need a heavy storefront to be useful if the operational flow is solid. For XYZ, this could become a focused storefront, a lightweight commerce product, or a more operational print-and-delivery concept if the workflow proves useful in practice. If you are working on apparel ordering, print-service coordination, delivery routing, or lightweight commerce experiences and want to shape this further, please contact us. We are open to discussing it. For the wider operating logic behind a concept like this, read What if time to market was measured in hours or days instead of months or years? and Getting Good Ideas Unstuck . On the service side, this kind of workflow often connects naturally to a Promptable Website or an existing website migration .


Title: Timeless Prints
URL: https://formationxyz.com/mvps/timeless-print-shop/
Description: A venture concept for the storefront where customers will be able to order prints from Timeless Colours' colourising and restoration service.
Body: Timeless Prints is an idea in motion for the place where people will be able to order prints from Timeless Colours’ colourising and restoration service. The goal is straightforward: once an image has been restored or colourised, there should be a clear and credible way for the customer to order a finished print without extra back and forth. The concept focuses on a simple storefront, reliable ordering, practical print options, and a smooth path from approved image to delivered print. It is not meant to be a bloated ecommerce suite. It is meant to support a specific service clearly and make ordering feel easy, trustworthy, and operationally clean. For XYZ, this could become the dedicated storefront for Timeless Colours, a service-backed ordering experience, or a print business that expands over time with the right production and fulfillment partners. There is room to explore format selection, print quality tiers, delivery handling, reorder flows, and the overall customer journey around preserved family and heritage imagery. If you are working on print fulfillment, restoration services, or customer ordering flows in this space and want to shape this further, please contact us. We are open to discussing it. For the broader logic behind making a storefront like this operationally useful, read You do not need artisanal websites anymore and Getting Good Ideas Unstuck . If you want a practical entry point, compare Promptable Website , Agentic Webmaster , and existing website migration .


Title: Your Idea?
URL: https://formationxyz.com/mvps/your-idea/
Description: A standing invitation to bring new ideas, interesting suggestions, and possible business opportunities to XYZ so we can explore whether they are worth shaping together.
Body: Your Idea? is a simple invitation to start a conversation with XYZ when you have something new, commercially interesting, or operationally valuable that you want to explore further. Not every strong opportunity starts as a finished brief. Sometimes it begins as a rough idea, a market signal, a technical hunch, or a business opportunity that needs the right partner to shape it into something more concrete. Please get in touch with us if you’ve got new ideas, interesting suggestions, or possible business opportunities. We’re always happy to talk. If you want to understand how we approach early-stage concepts, read Getting Good Ideas Unstuck . If you already want a more structured starting point, compare a Deep Dive , a Roadmap Audit , or the full services overview .


Title: Frontline Email Agent
URL: https://formationxyz.com/mvps/agentic-email-support/
Description: An MVP for a public-facing email frontline that answers common questions, gathers feedback, supports tickets, and escalates cleanly when needed.
Body: Frontline Email Agent is an email-first buffer for public inbound questions. It can answer common questions from approved source material, collect company or product feedback, handle first-line ticket support, ask for missing details, and escalate cleanly when a person should take over. People use normal email. They can reply to a thread, attach a screenshot, forward context, and keep going. You can try the current mail agent by sending a real question to mail-agent@formationxyz.com . It currently answers questions about FORMATION XYZ from this website. Email is still massive. The International Telecommunication Union says 6 billion people were online in 2025, or 74% of the world population . Google said in May 2026 that 3 billion users rely on Gmail . Google also said Gmail blocks nearly 15 billion unwanted emails every day , and Cloudflare reported that 4.3% of emails it analyzed in 2024 were malicious . Support built on top of email needs current source material and hard boundaries. Most companies already maintain the material their public audience needs: websites, product docs, FAQs, help articles, onboarding notes, policies, release notes, ticket categories, and internal guidance. The useful version of this product is not a free-form inbox chatbot. It is driven by specific knowledge bases that the company has approved, scoped, and kept current. The agent retrieves from that approved material before it answers or routes the case. We can create those knowledge bases for you, usually by bringing existing sources together into one governed layer with clear guard rails. For more detail, read our deeper article on why Without Knowledge, AI is powerless . Email works well for this: No signup is needed. People can simply send a message. Almost everyone online knows how to send email. There are billions of email users. Email conversations are authenticated enough for many support workflows. Login flows often prove account ownership by sending a link or code to an inbox, and companies already use email addresses as customer handles. A fresh incoming email is not enough on its own because mail headers can be forged. But subsequent replies that include information sent by the agent confirm receipt and practical control of that inbox. Many company processes already run through shared inboxes. Threads, forwarded messages, attachments, and CCs carry useful structure and context for an agent to work with. First-line AI replies can handle questions that are answerable from existing material, so people can focus on cases that need judgment or more help. The agent can classify inbound messages as support, feedback, sales, partnership, press, vendor, spam, or unknown, then route or summarize them for the right owner. For ticket-like cases, the agent can ask clarifying questions, capture the issue, collect screenshots or account context, and hand over a cleaner case to the support team. How it works Company-approved websites, documents, FAQs, policies, and similar material become one or more knowledge bases that refresh when the source changes. Before the agent answers, it retrieves the most relevant material for the question. The agent classifies the inbound message, decides whether it can answer, should ask for more detail, or should route the case. Guard rails keep the reply on topic, limit what the agent may answer, and stop it from bluffing when the source material is thin or missing. If a case needs a human decision, account context, commercial judgment, or support ownership, the agent can route it and CC the right person. The agent can read the thread, track prior messages, and use that history when it answers. Customers do not need to restate the same issue every time the conversation moves forward. Answer what the source material can answer. Capture useful feedback. Clean up ticket-like requests. Stay inside the approved scope. Escalate when a person should step in.

## Legal and utility pages
Title: About XYZ
URL: https://formationxyz.com/about/
Description: Meet the people behind XYZ by FORMATION and see who leads the work.


Title: Book a Meeting with Us
URL: https://formationxyz.com/book-meeting/
Description: Choose a 30-minute discovery call slot with XYZ by FORMATION.


Title: FAQ
URL: https://formationxyz.com/faq/
Description: Frequently asked questions about what XYZ is, what we offer, and how teams work with us.


Title: Imprint
URL: https://formationxyz.com/imprint/
Description: Legal notice and company information for XYZ, a division of FORMATION GmbH.


Title: Privacy Policy
URL: https://formationxyz.com/privacy-policy/
Description: Privacy information for XYZ, a division of FORMATION GmbH.


Title: Search
URL: https://formationxyz.com/search/
Description: Search services, MVPs, and pages.


Title: Sitemap
URL: https://formationxyz.com/sitemap/
Description: A crawler-friendly link list for the XYZ website.


Title: Specialist Agents
URL: https://formationxyz.com/specialist-agents/
Description: We install AI coworkers that remove operational bottlenecks for teams under 100 people.