# F200.ai AI Workforce Factory: AI workers, your own company AI and coding agents in your delivery, built by engineers on a governed cloud. We work with AWS, Google Cloud, Azure and Oracle Cloud (OCI). ## Founders - Anton Grishko: Co-founder · Product & Engineering. Anton has built and run infrastructure since 2005 and has worked as a DevOps architect for over ten years. In the Google Cloud unit of a large IT services firm, he led complex migrations of large enterprises to Google Cloud and spoke at Google events. Before that he led DevOps teams for enterprise and product companies, and he went on to serve as a chief architect. At F200.ai he leads product and engineering. - Ivan Hilevych: Co-founder · Business Development. Ivan has spent over ten years helping tech startups and growing companies find engineering teams that deliver. He has led sales for R&D and DevOps services companies as Chief Sales Officer and Head of Sales, and managed strategic enterprise accounts at a Microsoft partner. He works relationship-first: an honest conversation about fit comes before any deal. At F200.ai he leads business development. ## Team We have run production infrastructure since the mid-2000s, from telecom platforms and enterprise data centres to multi-cloud estates on AWS, Google Cloud and Azure. Between us: large enterprise migrations to Google Cloud, a cross-cloud migration of hundreds of microservices, DevSecOps and secure-SDLC programmes, SRE practices and cloud cost optimisation for retail, fintech, real-estate and enterprise software companies. More recently we have worked on GenAI solution architecture (RAG and knowledge bases, evaluation frameworks, guardrails and security for LLM applications) and agentic software delivery with human-in-the-loop controls, which is the practice behind our software factory. On the commercial side, we bring over ten years of building delivery partnerships with startups and growing companies. [Book a 30-min call with the founders](https://calendar.app.google/URDL4Q2mMJMnoSJK6), or use the [contact form](https://f200.ai/#contact). ## Cloud & DevOps Cloud and platform engineering on AWS, Google Cloud, Azure and Oracle Cloud (OCI): infrastructure as code, CI/CD, observability, and migrations, including between clouds. - ID: service.cloud-devops - Category: Service - Status: Available - Availability and pricing: contact required - Source: https://f200.ai/services/cloud-devops ## AI SRE & on-call Fewer incidents and faster recovery: reliability engineering, service-level objectives, and on-call and incident response with AI assistance and your people in charge, across the clouds we work with. - ID: service.sre - Category: Service - Status: Available - Availability and pricing: contact required - Source: https://f200.ai/services/sre ## SecOps & cloud governance Stop risky access before it becomes a breach: guardrails defined in Git and enforced across your cloud organisation, with access risk detection, time-boxed containment and compliance evidence. - ID: service.secops - Category: Service - Status: Available - Powered by: Sternguard (https://f200.ai/products/sternguard) - Availability and pricing: contact required - Source: https://f200.ai/services/secops ## FinOps Know where every dollar goes and stop the waste: cost reviews, budgets and guardrails, commitments and rightsizing, and cost anomaly response, across the clouds we work with. - ID: service.finops - Category: Service - Status: Available - Powered by: Sternguard (https://f200.ai/products/sternguard) - Availability and pricing: contact required - Source: https://f200.ai/services/finops ## Frontier Engineering Frontier AI built for your company: a company memory that keeps every decision with its source, your own models trained on your work, and AI workers, each evaluated before it ships. - ID: service.ai-engineering - Category: Service - Status: Available - Availability and pricing: contact required - Source: https://f200.ai/services/frontier-engineering ## Fine-tuning and your own models Models adapted to your domain, from embeddings, rerankers and classifiers to judgment models, with dataset review, evaluation design and deployment guidance; evaluations decide what ships. - ID: service.fine-tuning - Category: Service (part of Frontier Engineering) - Status: Available - Availability and pricing: contact required - Source: https://f200.ai/services/frontier-engineering/fine-tuning ## Company Memory An AI brain for your company: context engineering that keeps decisions with their sources, from your documents, runbooks and code, and serves them to your people and agents. - ID: service.company-memory - Category: Service (part of Frontier Engineering) - Status: Available - Powered by: Kanerva (https://f200.ai/products/kanerva) - Availability and pricing: contact required - Source: https://f200.ai/services/frontier-engineering/company-memory ## AI workers AI workers and AI engineers that take on repetitive work: automations, ticket, email and call handling, and engineering tasks, with your people approving what matters. - ID: service.ai-workers - Category: Service (part of Frontier Engineering) - Status: Available - Availability and pricing: contact required - Source: https://f200.ai/services/frontier-engineering/ai-workers ## Software Factory Integration Integrate an AI-assisted software factory into your established S-SDLC, under governance controls that span it: delivery stages, security controls, approvals, policies and audit evidence. - ID: service.software-factory-integration - Category: Service - Status: Available - Availability and pricing: contact required - Source: https://f200.ai/services/software-factory-integration ## Sternguard Cloud governance and AI SecOps: guardrails in Git, enforced across your cloud organisation, with risky-access containment and compliance evidence. AWS today. Google Cloud, Azure and Oracle Cloud next. - ID: product.cloud-governance - Category: Product - Status: Early access - Availability and pricing: contact required - Source: https://f200.ai/products/sternguard ## Shiftyard + YardBridge Shiftyard is an open-source software factory for coding agents, in pre-release: governed delivery on your own machines. YardBridge, its paid organisation layer, is in early access. - ID: product.software-factory - Category: Product - Status: Open source · pre-release - Availability and pricing: contact required - Source: https://f200.ai/products/shiftyard ## Kanerva A second brain for people and AI agents. Ingest the knowledge you connect or upload, keep it with its sources, and use the same memory across tools and sessions. Coming soon. - ID: product.engineering-memory - Category: Product - Status: Open source · coming soon - Availability and pricing: contact required - Source: https://f200.ai/products/kanerva ## Tillerpin A System-1 model for fast, typed decisions (yes/no, choice and relations), designed for calibrated decision-making in agent pipelines, with open weights and documented training data. Coming soon. - ID: product.decision-model - Category: Product - Status: Coming soon - Availability and pricing: contact required - Source: https://f200.ai/products/tillerpin ## Solutions Four outcomes: an AI workforce, company intelligence, a software factory and the cloud foundation they run on. Each has a fixed-scope way to start; services deliver them and products power them where noted. ### AI workforce - ID: solution.ai-workforce - Delivered by: AI workers, Company Memory, SecOps & cloud governance, Tillerpin - Start with: AI workforce pilot. We pick one workflow with you, map how it runs today, and build an AI worker for it with human approval at the points you choose. Deliverables: A working AI worker on one workflow, in your account; Its evaluation against how the work runs today; A decision on what to extend next. - Source: https://f200.ai/solutions#ai-workforce ### Company intelligence - ID: solution.company-ai - Delivered by: Frontier Engineering, Fine-tuning and your own models, Company Memory, Kanerva, Tillerpin - Start with: Company AI readiness review. We review the knowledge, decisions and tasks your AI should learn from, the permissions and privacy rules on that data, and how success will be evaluated. Deliverables: A design for your company memory and models; An evaluation plan that decides what ships; A scoped first build. - Source: https://f200.ai/solutions#company-intelligence ### Software factory - ID: solution.ai-delivery - Delivered by: Software Factory Integration, Shiftyard + YardBridge, Kanerva - Start with: Factory fit assessment. We map your S-SDLC stages, security controls, review gates and approvals against agent-assisted delivery, and choose the repository to pilot on. Deliverables: An integration design for your SDLC; The gates and policies agent work must pass; A pilot plan on one repository. - Source: https://f200.ai/solutions#software-factory ### Cloud foundation - ID: solution.cloud-foundation - Delivered by: Cloud & DevOps, AI SRE & on-call, SecOps & cloud governance, FinOps, Sternguard - Start with: Cloud governance and cost review. We review your accounts, access, guardrails, reliability and spend across the clouds you run, and rank what to fix first. Deliverables: Findings on risky access, reliability gaps and waste; The guardrails to define in Git; A prioritised plan. - Source: https://f200.ai/solutions#cloud-foundation ## Editorial Read published [Insights](https://f200.ai/blog), [News](https://f200.ai/news) and [Careers](https://f200.ai/careers). The [editorial snapshot](https://f200.ai/content/editorial.json) contains only published records. Empty collections mean no entries are currently published. ## Interactions Read company and catalog → Search offerings → Optionally compose a view with the site’s AI → Open the contact form → Review and explicitly submit an inquiry Only confirmed browser inquiry submission stores contact data. No booking, payment or product execution. ## For agents Read the [website interaction contract](https://f200.ai/content/experience.json) for node actions, approved offering IDs and equivalent MCP tools. This is an F200.ai-specific extension, not a universal discovery standard. Read /content/catalog.json or connect to /mcp using MCP SDK v2 (2026-07-28). The public tools are read-only, including prepare_inquiry which hands off to the browser for explicit submission. No authenticated agent submission is exposed. Server-card discovery is experimental. ## Published checks Read /content/quality.json for dated automated content-consistency evidence and its limits. This is not a security or performance audit. ## Limits No public prices, service-level guarantees, customer claims or supported-platform commitments are published. The products listed here are not run from this website; it supports company exploration and project inquiries. The site’s AI selects approved content and layouts. It does not generate executable UI code or authorize submissions. Updated 2026-10-08; content revision 2026-10-08.4. ## Currently published editorial - [Explore F200.ai with your AI assistant](https://f200.ai/news/explore-f200-with-your-ai-assistant.md) (news, 2026-10-07T21:46:48.799Z): F200.ai’s public MCP endpoint and agent-readable website let AI assistants explore our offerings and read published articles from the same sources as website visitors. - [DevOps Engineer](https://f200.ai/careers/devops-engineer.md) (vacancies, 2026-10-07T21:44:20.060Z): Help build and operate the cloud foundation behind F200.ai’s AI workforce and software factory work. We’re looking for a DevOps engineer who values automation, reliable delivery and clear operational practices. - [Inside Shiftyard: a governed software factory for coding agents on your own machines](https://f200.ai/blog/inside-shiftyard-governed-software-factory-for-coding-agents.md) (posts, 2026-10-07T20:17:09.826Z): A deep technical tour of Shiftyard, f200's pre-release, Apache-2.0 daemon that runs unmodified coding-agent CLIs under a queue, leases with fences, a deterministic policy gate, verified turns and a merge train: architecture, the gate's decision ladder, memory and model-selection gates, tests, measurements, and what is built versus planned. - [Software factories: why every company, from enterprise to solo founder, needs one](https://f200.ai/blog/software-factories-why-every-company-needs-one.md) (posts, 2026-10-07T19:59:45.685Z): AI agents can now do day-long engineering tasks, and almost every developer uses AI. Yet company-level gains are elusive. The research shows why: value comes from the system around the agents. A business guide for CEOs, product founders and solo builders, with data from 40+ studies, case studies and a 90-day plan. Editorial revision: f19aa4da224581732283326dfc7569678839b68f12285a78b479d792fdcd673d. Source: https://f200.ai/ AI Workforce Factory # AI agents that know your company and work inside your cloud. We help engineering teams put AI agents into production workflows, connect them to company knowledge, and keep engineers in control of delivery. [Book a 30-min call with the founders ](https://calendar.app.google/URDL4Q2mMJMnoSJK6) [Tell us your problem](https://f200.ai/#contact) For platform teams, engineering leaders and companies moving beyond an AI pilot. We work with AWS, Google Cloud, Azure and Oracle Cloud (OCI). Engineers approve what matters - Intent - Agents - Gates - Production Fixes and feedback flow back to the agents ## From an incident to a reviewed change. See how company context, an agent and an engineer come together in one workflow. Illustrative workflow Service health alert → investigated cause → reviewed change Explore the six steps ### Detect An alert becomes a scoped investigation. See the details Input · incident alert A service health alert identifies the affected workload. The incident defines what the agent may investigate and which engineer owns the response. ### Gather context Logs, runbooks and relevant history, together. See the details Context · linked evidence The agent gathers the permitted logs, recent deployment changes and related runbook entries. Each finding keeps a link to its source, so the engineer can check the reasoning. ### Propose a fix A proposed change with a reason and rollback plan. See the details Output · change proposal A recent configuration change is a possible cause. The agent proposes reverting it, explains the evidence and describes the risk and rollback path. A proposal is ready for review, not a production action. ### Engineer review A person decides whether the change should proceed. See the decision Decision · approval or revision The engineer reviews the source evidence and proposed change. They can approve, reject or ask for more investigation. The workflow only continues under the permissions agreed for the pilot. ### Validate Checks decide whether the result is acceptable. See the details Check · tests and service health The approved change passes the agreed tests and deployment checks. The service is observed against its health criteria; a failed check stops the workflow and returns it for investigation. ### Record Keep the outcome and its decision trail. See the details Record · incident summary The incident record links the evidence, proposal, reviewer decision and validation result. The reviewed outcome can inform the next investigation and updates to the runbook. An example of a workflow we can scope with you. This is an illustration, not a customer incident or a live product demo. Bring one runbook or recurring incident. We’ll discuss where an agent could help and what a useful pilot would need to prove. [Explore AI SRE & on-call](https://f200.ai/services/sre)[Tell us your problem](https://f200.ai/#contact) ### A live example you can inspect: this website. People and AI assistants read the same published offerings and articles. Check the catalog, read company information as Markdown, or connect an assistant through our public MCP endpoint. - [Inspect the catalog](https://f200.ai/content/catalog.json) - [Read the Markdown](https://f200.ai/index.md) - [Explore with your AI assistant](https://f200.ai/agents) Live website example ### An assistant finds a service and prepares an inquiry. “We need help with incident response and on-call reliability.” - Discover the available tools. - Read the published SRE offering. - Prepare a brief for you to review. This scripted demonstration calls our real public MCP endpoint. It uses a fixed example, without model inference. Inquiry preparation sends no email and stores no contact details. Run the assistant example ## What is slowing your team down? Choose the problem you want to solve. Start with a scoped service engagement, with clear deliverables before you commit to a wider rollout. ### Routine work keeps your team in the queue. Put an AI worker on one workflow, or first map the company knowledge it needs. Available service · Where to start [AI workforce pilot](https://f200.ai/?interest=solution.ai-workforce&intent=start#contact) We pick one workflow with you, map how it runs today, and build an AI worker for it with human approval at the points you choose. - A working AI worker on one workflow, in your account - Its evaluation against how the work runs today - A decision on what to extend next Supporting services and productsServices - [AI workers](https://f200.ai/services/frontier-engineering/ai-workers) - [Company Memory](https://f200.ai/services/frontier-engineering/company-memory) - [SecOps & cloud governance](https://f200.ai/services/secops) Products - [Tillerpin](https://f200.ai/products/tillerpin) [Explore ai workforce](https://f200.ai/solutions#ai-workforce)Need to plan your company AI first? Available service · Where to start [Company AI readiness review](https://f200.ai/?interest=solution.company-ai&intent=start#contact) We review the knowledge, decisions and tasks your AI should learn from, the permissions and privacy rules on that data, and how success will be evaluated. - A design for your company memory and models - An evaluation plan that decides what ships - A scoped first build Supporting services and productsServices - [Frontier Engineering](https://f200.ai/services/frontier-engineering) - [Fine-tuning and your own models](https://f200.ai/services/frontier-engineering/fine-tuning) - [Company Memory](https://f200.ai/services/frontier-engineering/company-memory) Products - [Kanerva](https://f200.ai/products/kanerva) - [Tillerpin](https://f200.ai/products/tillerpin) [Explore company intelligence](https://f200.ai/solutions#company-intelligence) ### Coding agents need a path into production. Integrate agent work into your repository and delivery process, with clear review points. Available service · Where to start [Factory fit assessment](https://f200.ai/?interest=solution.ai-delivery&intent=start#contact) We map your S-SDLC stages, security controls, review gates and approvals against agent-assisted delivery, and choose the repository to pilot on. - An integration design for your SDLC - The gates and policies agent work must pass - A pilot plan on one repository Supporting services and productsServices - [Software Factory Integration](https://f200.ai/services/software-factory-integration) Products - [Shiftyard + YardBridge](https://f200.ai/products/shiftyard) - [Kanerva](https://f200.ai/products/kanerva) [Explore software factory](https://f200.ai/solutions#software-factory) ### Your cloud needs a stronger foundation. Find the reliability, access and cost gaps to address before you scale. Available service · Where to start [Cloud governance and cost review](https://f200.ai/?interest=solution.cloud-foundation&intent=start#contact) We review your accounts, access, guardrails, reliability and spend across the clouds you run, and rank what to fix first. - Findings on risky access, reliability gaps and waste - The guardrails to define in Git - A prioritised plan Supporting services and productsServices - [Cloud & DevOps](https://f200.ai/services/cloud-devops) - [AI SRE & on-call](https://f200.ai/services/sre) - [SecOps & cloud governance](https://f200.ai/services/secops) - [FinOps](https://f200.ai/services/finops) Products - [Sternguard](https://f200.ai/products/sternguard) [Explore cloud foundation](https://f200.ai/solutions#cloud-foundation) Scope, timeline and commercial terms are agreed before work starts. Bring your constraints to the first conversation; we’ll choose the smallest useful engagement together. ## Engineering services you can start with today. Work with our engineers on your cloud, reliability, security, costs or AI delivery. The products supporting this work are listed afterward, with their current availability. ### Available services - [Cloud & DevOps](https://f200.ai/services/cloud-devops) A faster, leaner, observable platform. - [AI SRE & on-call](https://f200.ai/services/sre) Fewer incidents, faster recovery, AI on call with your people in charge. - [SecOps & cloud governance](https://f200.ai/services/secops) Stop risky access before it becomes a breach. - [FinOps](https://f200.ai/services/finops) Know where every dollar goes and stop the waste. - [Frontier Engineering](https://f200.ai/services/frontier-engineering) AI that learns how your business works. - [Fine-tuning and your own models](https://f200.ai/services/frontier-engineering/fine-tuning) - [Company Memory](https://f200.ai/services/frontier-engineering/company-memory) - [AI workers](https://f200.ai/services/frontier-engineering/ai-workers) - [Software Factory Integration](https://f200.ai/services/software-factory-integration) AI-assisted delivery your auditors can sign off. ### Products · current availability #### [Sternguard](https://f200.ai/products/sternguard) Cloud governance and AI SecOps: guardrails in Git, enforced across your cloud organisation, with risky-access containment and compliance evidence. AWS today. Google Cloud, Azure and Oracle Cloud next. - Early access #### [Shiftyard + YardBridge](https://f200.ai/products/shiftyard) Shiftyard is an open-source software factory for coding agents, in pre-release: governed delivery on your own machines. YardBridge, its paid organisation layer, is in early access. - Shiftyard: Open source · pre-release - YardBridge: Early access #### [Kanerva](https://f200.ai/products/kanerva) A second brain for people and AI agents. Ingest the knowledge you connect or upload, keep it with its sources, and use the same memory across tools and sessions. Coming soon. - Open source · coming soon #### [Tillerpin](https://f200.ai/products/tillerpin) A System-1 model for fast, typed decisions (yes/no, choice and relations), designed for calibrated decision-making in agent pipelines, with open weights and documented training data. Coming soon. - Coming soon ## One operating model, from pilot to production. ### Assess We start in your cloud account, from the outcome you need and the constraints you have. ### Build under controls and evals Governance controls and evaluations decide what ships, with a human approving what matters. ### Run and improve We stay accountable after go-live and keep improving what we built. Explore the architecture and delivery principles ### Intent Humans set the intent and the policy agents work within. ### Agents Agents do the work, with every step traced for review. ### Gates Every change is validated; a failed check goes back to the agents. ### Production An engineer approves and releases the accepted result. ### Day 2 operations Self-healing DevOps, SecOps and FinOps. Customer bug reports and feedback loops. Humans People watch and steer every stage. Nothing ships unreviewed. ### Your cloud, your data, your rules. - Designed to run in your account - Human approval where it matters - Open source and open weights where we can - Evaluations decide what ships ## Built by engineers, accountable for results. ### Founders - Anton Grishko Co-founder · Product & Engineering Anton has built and run infrastructure since 2005 and has worked as a DevOps architect for over ten years. In the Google Cloud unit of a large IT services firm, he led complex migrations of large enterprises to Google Cloud and spoke at Google events. Before that he led DevOps teams for enterprise and product companies, and he went on to serve as a chief architect. At F200.ai he leads product and engineering. - Ivan Hilevych Co-founder · Business Development Ivan has spent over ten years helping tech startups and growing companies find engineering teams that deliver. He has led sales for R&D and DevOps services companies as Chief Sales Officer and Head of Sales, and managed strategic enterprise accounts at a Microsoft partner. He works relationship-first: an honest conversation about fit comes before any deal. At F200.ai he leads business development. ### The team We have run production infrastructure since the mid-2000s, from telecom platforms and enterprise data centres to multi-cloud estates on AWS, Google Cloud and Azure. Between us: large enterprise migrations to Google Cloud, a cross-cloud migration of hundreds of microservices, DevSecOps and secure-SDLC programmes, SRE practices and cloud cost optimisation for retail, fintech, real-estate and enterprise software companies. More recently we have worked on GenAI solution architecture (RAG and knowledge bases, evaluation frameworks, guardrails and security for LLM applications) and agentic software delivery with human-in-the-loop controls, which is the practice behind our software factory. On the commercial side, we bring over ten years of building delivery partnerships with startups and growing companies. - [Cloud platforms and migrations](https://f200.ai/services/cloud-devops) - [Security and governance](https://f200.ai/services/secops) - [SRE and operations](https://f200.ai/services/sre) - [FinOps](https://f200.ai/services/finops) - [GenAI and agentic delivery](https://f200.ai/services/frontier-engineering) [Book a 30-min call with the founders ](https://calendar.app.google/URDL4Q2mMJMnoSJK6) ## Built on the tools your team already uses. We work across cloud platforms, delivery pipelines, observability and AI tooling. Explore the stack when you need the technical detail. Explore our engineering stack ### Clouds - AWS - Google Cloud - Azure - Oracle Cloud (OCI) ### Platform and infrastructure as code - Kubernetes - Terraform - OpenTofu - Terragrunt - Helm ### GitOps and delivery - Argo CD - GitHub Actions ### Security and secrets - Istio - HashiCorp Vault - Trivy ### Observability - Prometheus - Grafana - OpenTelemetry ### Data - PostgreSQL - Redis - Apache Kafka - ClickHouse - OpenSearch ### AI services and models - Amazon Bedrock - Google Gemini - Anthropic Claude - OpenAI - Hugging Face - PyTorch - Model Context Protocol ## Tell us your goal. Describe a goal and the site’s AI suggests the services, products and solutions that fit. Take your picks into the inquiry at the end of this page. Find services for your goal Your goal Find my starting point Keep personal or confidential details out of this field. Everything stays available without it. ## Start with the problem. Prefer to talk first? Book a 30-minute call with the founders. [Book a 30-min call with the founders ](https://calendar.app.google/URDL4Q2mMJMnoSJK6) Describe your goal in the form below. You review your inquiry before anything is sent. [Tell us your problem](https://f200.ai/#contact) Contact ### What are you building next? Start with the problem. We’ll start with a conversation. Your nameWork emailWhat would you like to achieve?Company (optional)Choose specific interests (optional) You can leave this blank. We’ll help find the right starting point. I’m interested in (optional, pick any)ProductsSternguardShiftyard + YardBridgeKanervaTillerpinSolutionsAI workforceCompany intelligenceSoftware factoryCloud foundationServicesCloud & DevOpsAI SRE & on-callSecOps & cloud governanceFinOpsFrontier EngineeringFine-tuning and your own modelsCompany MemoryAI workersSoftware Factory Integration Your contact details and message are used to handle this inquiry. Please don’t send secrets. Review your inquiry Source: https://f200.ai/services [F200.ai](https://f200.ai/)Services # Services that build your AI workforce and the cloud it runs on. Six service families behind the AI Workforce Factory: Cloud & DevOps, AI SRE & on-call, SecOps & cloud governance, FinOps, Frontier Engineering and Software Factory Integration. [Book a 30-min call with the founders ](https://calendar.app.google/URDL4Q2mMJMnoSJK6)[Tell us your problem](https://f200.ai/#contact)[Explore Shiftyard](https://f200.ai/products/shiftyard)How an engagement runs - Assess - Build under controls and evals - Run and improve ## Problems we solve - Costs drift, access sprawls, on-call never sleeps, and AI pilots stall when nobody can show what the AI knew, decided or touched. - Hiring for every specialism at once, from DevOps and SRE to SecOps, FinOps and ML, is not realistic. ## What you own at the end - Human approval where it matters. - Open source and open weights where we can. - Evaluations decide what ships. ## The outcomes they deliver ### [AI workforce](https://f200.ai/solutions#ai-workforce) Teams whose people spend their days on repetitive tickets, email, calls or routine engineering tasks. - [AI workers](https://f200.ai/services/frontier-engineering/ai-workers) - [Company Memory](https://f200.ai/services/frontier-engineering/company-memory) - [SecOps & cloud governance](https://f200.ai/services/secops) ### [Company intelligence](https://f200.ai/solutions#company-intelligence) Companies that want AI that knows their business, not a generic tool bolted onto their files. - [Frontier Engineering](https://f200.ai/services/frontier-engineering) - [Fine-tuning and your own models](https://f200.ai/services/frontier-engineering/fine-tuning) - [Company Memory](https://f200.ai/services/frontier-engineering/company-memory) ### [Software factory](https://f200.ai/solutions#software-factory) Engineering leaders who want coding agents inside their delivery without weakening its controls. - [Software Factory Integration](https://f200.ai/services/software-factory-integration) ### [Cloud foundation](https://f200.ai/solutions#cloud-foundation) Teams whose cloud has grown faster than its guardrails, before or while they add AI to it. - [Cloud & DevOps](https://f200.ai/services/cloud-devops) - [AI SRE & on-call](https://f200.ai/services/sre) - [SecOps & cloud governance](https://f200.ai/services/secops) - [FinOps](https://f200.ai/services/finops) ## What we deliver ### [Cloud & DevOps](https://f200.ai/services/cloud-devops) A faster, leaner, observable platform. Cloud and platform engineering on AWS, Google Cloud, Azure and Oracle Cloud (OCI): infrastructure as code, CI/CD, observability, and migrations, including between clouds. ### [AI SRE & on-call](https://f200.ai/services/sre) Fewer incidents, faster recovery, AI on call with your people in charge. Fewer incidents and faster recovery: reliability engineering, service-level objectives, and on-call and incident response with AI assistance and your people in charge, across the clouds we work with. ### [SecOps & cloud governance](https://f200.ai/services/secops) Stop risky access before it becomes a breach. Stop risky access before it becomes a breach: guardrails defined in Git and enforced across your cloud organisation, with access risk detection, time-boxed containment and compliance evidence. ### [FinOps](https://f200.ai/services/finops) Know where every dollar goes and stop the waste. Know where every dollar goes and stop the waste: cost reviews, budgets and guardrails, commitments and rightsizing, and cost anomaly response, across the clouds we work with. ### [Frontier Engineering](https://f200.ai/services/frontier-engineering) AI that learns how your business works. Frontier AI built for your company: a company memory that keeps every decision with its source, your own models trained on your work, and AI workers, each evaluated before it ships. ### [Software Factory Integration](https://f200.ai/services/software-factory-integration) AI-assisted delivery your auditors can sign off. Integrate an AI-assisted software factory into your established S-SDLC, under governance controls that span it: delivery stages, security controls, approvals, policies and audit evidence. ## How an engagement runs ### Assess We start from the outcome, the constraints and the evidence your team needs, and scope the delivery team, milestones and commercial terms with you. ### Build under controls and evals Work ships under governance controls and evaluations, with a human approving what matters. ### Run and improve We stay accountable after go-live and keep improving what we built together. ## Related products ### [Sternguard](https://f200.ai/products/sternguard) Early access Cloud governance and AI SecOps: guardrails in Git, enforced across your cloud organisation, with risky-access containment and compliance evidence. AWS today. Google Cloud, Azure and Oracle Cloud next. ### [Shiftyard + YardBridge](https://f200.ai/products/shiftyard) Open source · pre-release Shiftyard is an open-source software factory for coding agents, in pre-release: governed delivery on your own machines. YardBridge, its paid organisation layer, is in early access. ### [Kanerva](https://f200.ai/products/kanerva) Open source · coming soon A second brain for people and AI agents. Ingest the knowledge you connect or upload, keep it with its sources, and use the same memory across tools and sessions. Coming soon. ### [Tillerpin](https://f200.ai/products/tillerpin) Coming soon A System-1 model for fast, typed decisions (yes/no, choice and relations), designed for calibrated decision-making in agent pipelines, with open weights and documented training data. Coming soon. ## Frequently asked questions ### Which clouds do you work with? We work with AWS, Google Cloud, Azure and Oracle Cloud (OCI). ### How do we start? Tell us your problem in the contact form, or book a call with the founders. We start from the outcome, the constraints and the evidence your team needs. ### Do you publish prices? No. Scope, the delivery team, milestones and commercial terms are agreed with you. ### Can my AI assistant read this page? Yes. This page is ordinary HTML that needs no AI call, and it is also served as Markdown. Your assistant can read the [published catalog](https://f200.ai/content/catalog.json) or connect through [F200.ai’s MCP interface](https://f200.ai/agents). ## Start with the problem. We’ll start with a conversation. [Book a 30-min call with the founders ](https://calendar.app.google/URDL4Q2mMJMnoSJK6)[Tell us your problem](https://f200.ai/#contact)[Explore Shiftyard](https://f200.ai/products/shiftyard) Source: https://f200.ai/products [F200.ai](https://f200.ai/)Products # The tooling behind our services. The F200.ai products: Sternguard, Shiftyard + YardBridge, Kanerva and Tillerpin. [Book a 30-min call with the founders ](https://calendar.app.google/URDL4Q2mMJMnoSJK6)[Tell us your problem](https://f200.ai/#contact)[Explore Shiftyard](https://f200.ai/products/shiftyard)The products - Sternguard - Shiftyard + YardBridge - Kanerva - Tillerpin ## The products ### [Sternguard](https://f200.ai/products/sternguard) Early access Cloud governance and AI SecOps: guardrails in Git, enforced across your cloud organisation, with risky-access containment and compliance evidence. AWS today. Google Cloud, Azure and Oracle Cloud next. ### [Shiftyard + YardBridge](https://f200.ai/products/shiftyard) Open source · pre-release Shiftyard is an open-source software factory for coding agents, in pre-release: governed delivery on your own machines. YardBridge, its paid organisation layer, is in early access. ### [Kanerva](https://f200.ai/products/kanerva) Open source · coming soon A second brain for people and AI agents. Ingest the knowledge you connect or upload, keep it with its sources, and use the same memory across tools and sessions. Coming soon. ### [Tillerpin](https://f200.ai/products/tillerpin) Coming soon A System-1 model for fast, typed decisions (yes/no, choice and relations), designed for calibrated decision-making in agent pipelines, with open weights and documented training data. Coming soon. ## Related services ### [Cloud & DevOps](https://f200.ai/services/cloud-devops) Cloud and platform engineering on AWS, Google Cloud, Azure and Oracle Cloud (OCI): infrastructure as code, CI/CD, observability, and migrations, including between clouds. ### [AI SRE & on-call](https://f200.ai/services/sre) Fewer incidents and faster recovery: reliability engineering, service-level objectives, and on-call and incident response with AI assistance and your people in charge, across the clouds we work with. ### [SecOps & cloud governance](https://f200.ai/services/secops) Stop risky access before it becomes a breach: guardrails defined in Git and enforced across your cloud organisation, with access risk detection, time-boxed containment and compliance evidence. ### [FinOps](https://f200.ai/services/finops) Know where every dollar goes and stop the waste: cost reviews, budgets and guardrails, commitments and rightsizing, and cost anomaly response, across the clouds we work with. ### [Frontier Engineering](https://f200.ai/services/frontier-engineering) Frontier AI built for your company: a company memory that keeps every decision with its source, your own models trained on your work, and AI workers, each evaluated before it ships. ### [Software Factory Integration](https://f200.ai/services/software-factory-integration) Integrate an AI-assisted software factory into your established S-SDLC, under governance controls that span it: delivery stages, security controls, approvals, policies and audit evidence. ## Frequently asked questions ### How do we get access? Each product page has its own request: early access, or a note when it is available. Both go to the same contact form. ### Do you publish prices? No. Scope and commercial terms are agreed with you. ### Can my AI assistant read this page? Yes. This page is ordinary HTML that needs no AI call, and it is also served as Markdown. Your assistant can read the [published catalog](https://f200.ai/content/catalog.json) or connect through [F200.ai’s MCP interface](https://f200.ai/agents). ## Start with the problem. We’ll start with a conversation. [Book a 30-min call with the founders ](https://calendar.app.google/URDL4Q2mMJMnoSJK6)[Tell us your problem](https://f200.ai/#contact)[Explore Shiftyard](https://f200.ai/products/shiftyard) Source: https://f200.ai/services/cloud-devops [F200.ai](https://f200.ai/)[Services](https://f200.ai/services)Cloud & DevOps # A faster, leaner, observable platform. Cloud and platform engineering on AWS, Google Cloud, Azure and Oracle Cloud (OCI): infrastructure as code, CI/CD, observability, and migrations, including between clouds. Available [Book a 30-min call with the founders ](https://calendar.app.google/URDL4Q2mMJMnoSJK6)[Fix your platform](https://f200.ai/#contact)[Explore Shiftyard](https://f200.ai/products/shiftyard)How it works - Workloads - Plan - Platform - Handover People and evidence stay in the flow ## Problems we solve - Your cloud is already the hard part, before anyone adds AI to it. - Hiring for every specialism at once, from DevOps to SRE, is not realistic. - Workloads have to move: onto a new platform, or from one cloud to another. ## What you own at the end - Your platform, with its infrastructure as code, CI/CD and observability. - An operational handover your team has agreed to. ## What we deliver ### Cloud and platform engineering On AWS, Google Cloud, Azure and Oracle Cloud (OCI). ### Migrations, including between clouds Planned around your workloads, dependencies, access controls and continuity requirements. ### Infrastructure as code ### CI/CD ### Observability ## How an engagement runs ### Assess We start from the outcome, the constraints and the evidence your team needs, and scope the delivery team, milestones and commercial terms with you. What we ask first: - Which workloads, environments and deployment workflows are in scope? - What is driving the change: delivery needs, operational constraints, a move between clouds or another requirement? - Which dependencies, access controls and continuity requirements need to be considered? - What would a successful migration and operational handover look like for your team? ### Build under controls and evals Work ships under governance controls and evaluations, with a human approving what matters. ### Run and improve We stay accountable after go-live and keep improving what we built together. ## Related services ### [AI SRE & on-call](https://f200.ai/services/sre) Fewer incidents and faster recovery: reliability engineering, service-level objectives, and on-call and incident response with AI assistance and your people in charge, across the clouds we work with. ### [SecOps & cloud governance](https://f200.ai/services/secops) Stop risky access before it becomes a breach: guardrails defined in Git and enforced across your cloud organisation, with access risk detection, time-boxed containment and compliance evidence. ### [FinOps](https://f200.ai/services/finops) Know where every dollar goes and stop the waste: cost reviews, budgets and guardrails, commitments and rightsizing, and cost anomaly response, across the clouds we work with. ## Frequently asked questions ### Which clouds do you work with? We work with AWS, Google Cloud, Azure and Oracle Cloud (OCI), including migrations between them. ### Do you publish service levels or fixed timelines? No. There are no published service-level guarantees or fixed migration timelines. Platform support, the migration approach and delivery commitments are confirmed during scoping. ### Do you publish prices? No. Scope, the delivery team, milestones and commercial terms are agreed with you. ### Can my AI assistant read this page? Yes. This page is ordinary HTML that needs no AI call, and it is also served as Markdown. Your assistant can read the [published catalog](https://f200.ai/content/catalog.json) or connect through [F200.ai’s MCP interface](https://f200.ai/agents) and retrieve this offering by its stable identifier: service.cloud-devops. ## Start with the problem. We’ll start with a conversation. [Book a 30-min call with the founders ](https://calendar.app.google/URDL4Q2mMJMnoSJK6)[Fix your platform](https://f200.ai/#contact)[Explore Shiftyard](https://f200.ai/products/shiftyard) Source: https://f200.ai/services/sre [F200.ai](https://f200.ai/)[Services](https://f200.ai/services)AI SRE & on-call # Fewer incidents, faster recovery, AI on call with your people in charge. Fewer incidents and faster recovery: reliability engineering, service-level objectives, and on-call and incident response with AI assistance and your people in charge, across the clouds we work with. Available [Book a 30-min call with the founders ](https://calendar.app.google/URDL4Q2mMJMnoSJK6)[Cut your incidents](https://f200.ai/#contact)[Explore Shiftyard](https://f200.ai/products/shiftyard)How it works - Signal - AI assists - People act - Improve People and evidence stay in the flow ## Problems we solve - On-call never sleeps, and every incident needs an answer. - Hiring a reliability team alongside every other specialism at once is not realistic. ## What you own at the end - Service-level objectives for the services that matter to you. - An on-call and incident response practice with your people in charge. ## What we deliver ### Reliability engineering Across AWS, Google Cloud, Azure and Oracle Cloud (OCI). ### Service-level objectives (SLOs) ### On-call and incident response with AI assistance AI assists; your people stay in charge. ## How an engagement runs ### Assess We start from the outcome, the constraints and the evidence your team needs, and scope the delivery team, milestones and commercial terms with you. ### Build under controls and evals Work ships under governance controls and evaluations, with a human approving what matters. ### Run and improve We stay accountable after go-live and keep improving what we built together. ## Related services ### [Cloud & DevOps](https://f200.ai/services/cloud-devops) Cloud and platform engineering on AWS, Google Cloud, Azure and Oracle Cloud (OCI): infrastructure as code, CI/CD, observability, and migrations, including between clouds. ## Frequently asked questions ### Which clouds do you work with? SRE is multi-cloud: we work with AWS, Google Cloud, Azure and Oracle Cloud (OCI). ### Who is in charge during an incident? Your people. AI assists with on-call and incident response; your people stay in charge. ### Do you publish prices? No. Scope, the delivery team, milestones and commercial terms are agreed with you. ### Can my AI assistant read this page? Yes. This page is ordinary HTML that needs no AI call, and it is also served as Markdown. Your assistant can read the [published catalog](https://f200.ai/content/catalog.json) or connect through [F200.ai’s MCP interface](https://f200.ai/agents) and retrieve this offering by its stable identifier: service.sre. ## Start with the problem. We’ll start with a conversation. [Book a 30-min call with the founders ](https://calendar.app.google/URDL4Q2mMJMnoSJK6)[Cut your incidents](https://f200.ai/#contact)[Explore Shiftyard](https://f200.ai/products/shiftyard) Source: https://f200.ai/services/secops [F200.ai](https://f200.ai/)[Services](https://f200.ai/services)SecOps & cloud governance # Stop risky access before it becomes a breach. Guardrails defined in Git and enforced across your cloud organisation, with access risk detection, time-boxed containment and compliance evidence. Available Powered by [Sternguard](https://f200.ai/products/sternguard) [Book a 30-min call with the founders ](https://calendar.app.google/URDL4Q2mMJMnoSJK6)[Stop risky access](https://f200.ai/#contact)[Request Sternguard early access](https://f200.ai/?interest=product.cloud-governance&intent=early-access#contact)How it works - Git policy - Detect risk - Contain - Evidence People and evidence stay in the flow ## Problems we solve - Access sprawls across accounts, and risky access can become a breach. - AI agents now act in your cloud, and nobody can show what an agent knew, decided or touched. ## What you own at the end - Your guardrails, defined in Git and enforced across your cloud organisation. - Compliance evidence for your organisation. - The governance tooling runs in your account. ## What we deliver We work with AWS, Google Cloud, Azure and Oracle Cloud (OCI). Our depth is greatest on AWS Organizations. ### Organisation-wide guardrails as code Defined in Git and enforced across your cloud organisation. ### Identity and access risk detection ### Time-boxed containment of risky access Risky access is detected and contained for a set time. ### Compliance evidence ### AI-agent governance ## How an engagement runs ### Assess We start from the outcome, the constraints and the evidence your team needs, and scope the delivery team, milestones and commercial terms with you. ### Build under controls and evals Work ships under governance controls and evaluations, with a human approving what matters. ### Run and improve We stay accountable after go-live and keep improving what we built together. ## Powered by Sternguard ### [Sternguard](https://f200.ai/products/sternguard) Early access Cloud governance and AI SecOps: guardrails in Git, enforced across your cloud organisation, with risky-access containment and compliance evidence. AWS today. Google Cloud, Azure and Oracle Cloud next. ## Related services ### [FinOps](https://f200.ai/services/finops) Know where every dollar goes and stop the waste: cost reviews, budgets and guardrails, commitments and rightsizing, and cost anomaly response, across the clouds we work with. ### [Cloud & DevOps](https://f200.ai/services/cloud-devops) Cloud and platform engineering on AWS, Google Cloud, Azure and Oracle Cloud (OCI): infrastructure as code, CI/CD, observability, and migrations, including between clouds. ### [Software Factory Integration](https://f200.ai/services/software-factory-integration) Integrate an AI-assisted software factory into your established S-SDLC, under governance controls that span it: delivery stages, security controls, approvals, policies and audit evidence. ## Frequently asked questions ### Which clouds does Sternguard cover? AWS today. Google Cloud, Azure and Oracle Cloud next. Sternguard is in early access. ### Do you publish prices? No. Scope, the delivery team, milestones and commercial terms are agreed with you. ### Can my AI assistant read this page? Yes. This page is ordinary HTML that needs no AI call, and it is also served as Markdown. Your assistant can read the [published catalog](https://f200.ai/content/catalog.json) or connect through [F200.ai’s MCP interface](https://f200.ai/agents) and retrieve this offering by its stable identifier: service.secops. ## Start with the problem. We’ll start with a conversation. [Book a 30-min call with the founders ](https://calendar.app.google/URDL4Q2mMJMnoSJK6)[Stop risky access](https://f200.ai/#contact)[Request Sternguard early access](https://f200.ai/?interest=product.cloud-governance&intent=early-access#contact) Source: https://f200.ai/services/finops [F200.ai](https://f200.ai/)[Services](https://f200.ai/services)FinOps # Know where every dollar goes and stop the waste. Cost reviews, budgets and guardrails, commitments and rightsizing, and cost anomaly response, across the clouds we work with. Available Powered by [Sternguard](https://f200.ai/products/sternguard) [Book a 30-min call with the founders ](https://calendar.app.google/URDL4Q2mMJMnoSJK6)[Stop the cloud waste](https://f200.ai/#contact)[Request Sternguard early access](https://f200.ai/?interest=product.cloud-governance&intent=early-access#contact)How it works - Review cost - Budget - Rightsize - Respond People and evidence stay in the flow ## Problems we solve - Costs drift, and nobody can say where every dollar goes. - Budgets that nobody enforces turn into waste. ## What you own at the end - A clear view of where every dollar goes. - Budgets and guardrails that enforce themselves. - The governance tooling runs in your account. ## What we deliver ### Cost reviews Multi-cloud: we work with AWS, Google Cloud, Azure and Oracle Cloud (OCI). ### Budgets and guardrails Budgets that enforce themselves. ### Commitments and rightsizing ### Cost anomaly response ## How an engagement runs ### Assess We start from the outcome, the constraints and the evidence your team needs, and scope the delivery team, milestones and commercial terms with you. ### Build under controls and evals Work ships under governance controls and evaluations, with a human approving what matters. ### Run and improve We stay accountable after go-live and keep improving what we built together. ## Powered by Sternguard ### [Sternguard](https://f200.ai/products/sternguard) Early access Cloud governance and AI SecOps: guardrails in Git, enforced across your cloud organisation, with risky-access containment and compliance evidence. AWS today. Google Cloud, Azure and Oracle Cloud next. ## Related services ### [Cloud & DevOps](https://f200.ai/services/cloud-devops) Cloud and platform engineering on AWS, Google Cloud, Azure and Oracle Cloud (OCI): infrastructure as code, CI/CD, observability, and migrations, including between clouds. ### [SecOps & cloud governance](https://f200.ai/services/secops) Stop risky access before it becomes a breach: guardrails defined in Git and enforced across your cloud organisation, with access risk detection, time-boxed containment and compliance evidence. ## Frequently asked questions ### Which clouds does Sternguard cover? AWS today. Google Cloud, Azure and Oracle Cloud next. Sternguard is in early access. ### Do you publish prices? No. Scope, the delivery team, milestones and commercial terms are agreed with you. ### Can my AI assistant read this page? Yes. This page is ordinary HTML that needs no AI call, and it is also served as Markdown. Your assistant can read the [published catalog](https://f200.ai/content/catalog.json) or connect through [F200.ai’s MCP interface](https://f200.ai/agents) and retrieve this offering by its stable identifier: service.finops. ## Start with the problem. We’ll start with a conversation. [Book a 30-min call with the founders ](https://calendar.app.google/URDL4Q2mMJMnoSJK6)[Stop the cloud waste](https://f200.ai/#contact)[Request Sternguard early access](https://f200.ai/?interest=product.cloud-governance&intent=early-access#contact) Source: https://f200.ai/services/frontier-engineering [F200.ai](https://f200.ai/)[Services](https://f200.ai/services)Frontier Engineering # AI that learns how your business works. Frontier AI built for your company: a company memory that keeps every decision with its source, your own models trained on your work, and AI workers, each evaluated before it ships. Available [Book a 30-min call with the founders ](https://calendar.app.google/URDL4Q2mMJMnoSJK6)[Get AI that knows your business](https://f200.ai/#contact)[Explore Shiftyard](https://f200.ai/products/shiftyard)How it works - Team work - Adapt model - Evaluate - Ship People and evidence stay in the flow ## Problems we solve - AI pilots stall because nobody can show what the AI knew, decided or touched. - Generic AI tools bolted onto company files are like giving a new temp your passwords. ## What you own at the end - Your own AI, in your account: you own it. - Models kept only when they win on held-out past work. - A company memory that keeps every decision with its source. ## What we deliver ### [Fine-tuning and your own models](https://f200.ai/services/frontier-engineering/fine-tuning) Models adapted to your domain, from embeddings, rerankers and classifiers to judgment models, with dataset review, evaluation design and deployment guidance; evaluations decide what ships. ### [Company Memory](https://f200.ai/services/frontier-engineering/company-memory) An AI brain for your company: context engineering that keeps decisions with their sources, from your documents, runbooks and code, and serves them to your people and agents. ### [AI workers](https://f200.ai/services/frontier-engineering/ai-workers) AI workers and AI engineers that take on repetitive work: automations, ticket, email and call handling, and engineering tasks, with your people approving what matters. ## How an engagement runs ### Assess We start from the outcome, the constraints and the evidence your team needs, and scope the delivery team, milestones and commercial terms with you. ### Build under controls and evals Work ships under governance controls and evaluations, with a human approving what matters. ### Run and improve We stay accountable after go-live and keep improving what we built together. ## Related products ### [Kanerva](https://f200.ai/products/kanerva) Open source · coming soon A second brain for people and AI agents. Ingest the knowledge you connect or upload, keep it with its sources, and use the same memory across tools and sessions. Coming soon. ### [Tillerpin](https://f200.ai/products/tillerpin) Coming soon A System-1 model for fast, typed decisions (yes/no, choice and relations), designed for calibrated decision-making in agent pipelines, with open weights and documented training data. Coming soon. ## Frequently asked questions ### Where does it run? In your account. You own what we build. ### How do you decide a model is good enough? Evaluations decide what ships: a model is kept only when it wins on held-out past work. ### Do you publish prices? No. Scope, the delivery team, milestones and commercial terms are agreed with you. ### Can my AI assistant read this page? Yes. This page is ordinary HTML that needs no AI call, and it is also served as Markdown. Your assistant can read the [published catalog](https://f200.ai/content/catalog.json) or connect through [F200.ai’s MCP interface](https://f200.ai/agents) and retrieve this offering by its stable identifier: service.ai-engineering. ## Start with the problem. We’ll start with a conversation. [Book a 30-min call with the founders ](https://calendar.app.google/URDL4Q2mMJMnoSJK6)[Get AI that knows your business](https://f200.ai/#contact)[Explore Shiftyard](https://f200.ai/products/shiftyard) Source: https://f200.ai/services/frontier-engineering/fine-tuning [F200.ai](https://f200.ai/)[Services](https://f200.ai/services)[Frontier Engineering](https://f200.ai/services/frontier-engineering)Fine-tuning and your own models # Your own models, kept only when they beat what you use today. Models adapted to your domain, from embeddings, rerankers and classifiers to judgment models, with dataset review, evaluation design and deployment guidance. Available [Book a 30-min call with the founders ](https://calendar.app.google/URDL4Q2mMJMnoSJK6)[Train your own model](https://f200.ai/#contact)[Explore Shiftyard](https://f200.ai/products/shiftyard)How it works - Examples - Adapt - Held-out eval - Keep winner People and evidence stay in the flow ## Problems we solve - A general model falls short on the task your business needs done. - Without evaluations, nobody can tell whether a new model is better. ## What you own at the end - Your own models, in your account. - The evaluations that decided what shipped. ## What we deliver ### Embeddings, rerankers and classifiers ### Judgment models ### Dataset review and evaluation design Your own models, trained on your team's work and kept only when they win on held-out past work. ### Deployment guidance ## How an engagement runs ### Assess We start from the outcome, the constraints and the evidence your team needs, and scope the delivery team, milestones and commercial terms with you. What we ask first: - Which task or domain should the model handle, and where does the current approach fall short? - What representative examples are available, and what permissions or privacy requirements apply to that data? - Which evaluation goals matter: task accuracy, consistency, latency or another measurable outcome? - Are there model, deployment or integration constraints that the engagement must account for? ### Build under controls and evals Work ships under governance controls and evaluations, with a human approving what matters. ### Run and improve We stay accountable after go-live and keep improving what we built together. ## Related product ### [Tillerpin](https://f200.ai/products/tillerpin) Coming soon A System-1 model for fast, typed decisions (yes/no, choice and relations), designed for calibrated decision-making in agent pipelines, with open weights and documented training data. Coming soon. ## Frequently asked questions ### Do you promise an accuracy improvement? No. Supported model families, the evaluation approach and the delivery scope are agreed with your team, and evaluations decide what ships. ### What data do you need? Representative examples of the task, with the permissions and privacy requirements that apply to that data. ### Do you publish prices? No. Scope, the delivery team, milestones and commercial terms are agreed with you. ### Can my AI assistant read this page? Yes. This page is ordinary HTML that needs no AI call, and it is also served as Markdown. Your assistant can read the [published catalog](https://f200.ai/content/catalog.json) or connect through [F200.ai’s MCP interface](https://f200.ai/agents) and retrieve this offering by its stable identifier: service.fine-tuning. ## Start with the problem. We’ll start with a conversation. [Book a 30-min call with the founders ](https://calendar.app.google/URDL4Q2mMJMnoSJK6)[Train your own model](https://f200.ai/#contact)[Explore Shiftyard](https://f200.ai/products/shiftyard) Source: https://f200.ai/services/frontier-engineering/company-memory [F200.ai](https://f200.ai/)[Services](https://f200.ai/services)[Frontier Engineering](https://f200.ai/services/frontier-engineering)Company Memory # An AI brain for your company, with sources. An AI brain for your company: context engineering that keeps decisions with their sources, from your documents, runbooks and code, and serves them to your people and agents. Available Powered by [Kanerva](https://f200.ai/products/kanerva) [Book a 30-min call with the founders ](https://calendar.app.google/URDL4Q2mMJMnoSJK6)[Build your company memory](https://f200.ai/#contact)[Explore Shiftyard](https://f200.ai/products/shiftyard)How it works - Decision - Source - Memory - Answer People and evidence stay in the flow ## Problems we solve - Generic AI tools bolted onto company files are like giving a new temp your passwords. - Decisions get lost, and nobody can show where an answer came from. ## What you own at the end - Your company memory, in your account. - Every decision with where it came from. ## What we deliver ### Context engineering ### Decisions kept with their sources ### Memory served to people and agents ## How an engagement runs ### Assess We start from the outcome, the constraints and the evidence your team needs, and scope the delivery team, milestones and commercial terms with you. ### Build under controls and evals Work ships under governance controls and evaluations, with a human approving what matters. ### Run and improve We stay accountable after go-live and keep improving what we built together. ## Powered by Kanerva ### [Kanerva](https://f200.ai/products/kanerva) Open source · coming soon A second brain for people and AI agents. Ingest the knowledge you connect or upload, keep it with its sources, and use the same memory across tools and sessions. Coming soon. ## Frequently asked questions ### Can we install Kanerva ourselves today? Not yet. Kanerva is open source and coming soon. Until it is public, Company Memory is delivered as a service. ### Who uses the memory? Your people and your agents: it serves decisions with their sources to both. ### Do you publish prices? No. Scope, the delivery team, milestones and commercial terms are agreed with you. ### Can my AI assistant read this page? Yes. This page is ordinary HTML that needs no AI call, and it is also served as Markdown. Your assistant can read the [published catalog](https://f200.ai/content/catalog.json) or connect through [F200.ai’s MCP interface](https://f200.ai/agents) and retrieve this offering by its stable identifier: service.company-memory. ## Start with the problem. We’ll start with a conversation. [Book a 30-min call with the founders ](https://calendar.app.google/URDL4Q2mMJMnoSJK6)[Build your company memory](https://f200.ai/#contact)[Explore Shiftyard](https://f200.ai/products/shiftyard) Source: https://f200.ai/services/frontier-engineering/ai-workers [F200.ai](https://f200.ai/)[Services](https://f200.ai/services)[Frontier Engineering](https://f200.ai/services/frontier-engineering)AI workers # AI workers that take on the repetitive work. AI workers and AI engineers that take on repetitive work: automations, ticket, email and call handling, and engineering tasks, with your people approving what matters. Available [Book a 30-min call with the founders ](https://calendar.app.google/URDL4Q2mMJMnoSJK6)[Offload the repetitive work](https://f200.ai/#contact)[Explore Shiftyard](https://f200.ai/products/shiftyard)How it works - Task - Worker - Human gate - Action People and evidence stay in the flow ## Problems we solve - Repetitive work takes your people's time: tickets, email, calls and routine engineering tasks. - Hiring for every specialism at once is not realistic. ## What you own at the end - AI workers that run in your account. - Human approval where it matters. ## What we deliver ### Automations ### Ticket, email and call handling ### Engineering tasks ## How an engagement runs ### Assess We start from the outcome, the constraints and the evidence your team needs, and scope the delivery team, milestones and commercial terms with you. ### Build under controls and evals Work ships under governance controls and evaluations, with a human approving what matters. ### Run and improve We stay accountable after go-live and keep improving what we built together. ## Frequently asked questions ### Who approves what an AI worker does? Your people. Work runs through gates, with a human approving what matters. ### Do you publish prices? No. Scope, the delivery team, milestones and commercial terms are agreed with you. ### Can my AI assistant read this page? Yes. This page is ordinary HTML that needs no AI call, and it is also served as Markdown. Your assistant can read the [published catalog](https://f200.ai/content/catalog.json) or connect through [F200.ai’s MCP interface](https://f200.ai/agents) and retrieve this offering by its stable identifier: service.ai-workers. ## Start with the problem. We’ll start with a conversation. [Book a 30-min call with the founders ](https://calendar.app.google/URDL4Q2mMJMnoSJK6)[Offload the repetitive work](https://f200.ai/#contact)[Explore Shiftyard](https://f200.ai/products/shiftyard) Source: https://f200.ai/services/software-factory-integration [F200.ai](https://f200.ai/)[Services](https://f200.ai/services)Software Factory Integration # AI-assisted delivery your auditors can sign off. Integrate an AI-assisted software factory into your established S-SDLC, under governance controls that span it: delivery stages, security controls, approvals, policies and audit evidence. Available [Book a 30-min call with the founders ](https://calendar.app.google/URDL4Q2mMJMnoSJK6)[Bring agents into your SDLC](https://f200.ai/#contact)[Explore Shiftyard](https://f200.ai/products/shiftyard)How it works - Existing SDLC - Agent steps - Review gates - Evidence People and evidence stay in the flow ## Problems we solve - Agents are fast, but delivery isn't: work in progress piles up, reviews become the bottleneck and nothing is auditable. - Agent work has to fit the security controls and approval gates you already run, without weakening them. ## What you own at the end - Your S-SDLC, with the factory fitted to it rather than replacing it. - Traceability and audit evidence for agent work. ## What we deliver ### Fit AI-assisted delivery into your existing SDLC ### Governance controls across delivery: security, policy and audit evidence ### Approvals and governance policies ## How an engagement runs ### Assess We start from the outcome, the constraints and the evidence your team needs, and scope the delivery team, milestones and commercial terms with you. What we ask first: - Which S-SDLC stages, security controls and approval gates must the factory operate inside? - How do your repositories, branching model, code review and release approvals work today? - Which governance policies apply to agent access, segregation of duties, traceability and audit evidence? - How will you assess the integration against your existing delivery and compliance requirements? ### Build under controls and evals Work ships under governance controls and evaluations, with a human approving what matters. ### Run and improve We stay accountable after go-live and keep improving what we built together. ## Related product ### [Shiftyard + YardBridge](https://f200.ai/products/shiftyard) Open source · pre-release Shiftyard is an open-source software factory for coding agents, in pre-release: governed delivery on your own machines. YardBridge, its paid organisation layer, is in early access. ## Related services ### [SecOps & cloud governance](https://f200.ai/services/secops) Stop risky access before it becomes a breach: guardrails defined in Git and enforced across your cloud organisation, with access risk detection, time-boxed containment and compliance evidence. ## Frequently asked questions ### Does this replace our SDLC? No. The factory is fitted to your established S-SDLC processes and governance policies; it does not replace them. ### Does browsing this site give an agent access to our repositories? No. Browsing this website does not run a factory or grant an agent access to your repositories. ### Do you publish prices? No. Scope, the delivery team, milestones and commercial terms are agreed with you. ### Can my AI assistant read this page? Yes. This page is ordinary HTML that needs no AI call, and it is also served as Markdown. Your assistant can read the [published catalog](https://f200.ai/content/catalog.json) or connect through [F200.ai’s MCP interface](https://f200.ai/agents) and retrieve this offering by its stable identifier: service.software-factory-integration. ## Start with the problem. We’ll start with a conversation. [Book a 30-min call with the founders ](https://calendar.app.google/URDL4Q2mMJMnoSJK6)[Bring agents into your SDLC](https://f200.ai/#contact)[Explore Shiftyard](https://f200.ai/products/shiftyard) Source: https://f200.ai/products/sternguard [F200.ai](https://f200.ai/)[Products](https://f200.ai/products)Sternguard # Other tools find problems. Sternguard prevents them. AI SecOps for AWS Organizations. Write guardrails as code, prove what each change would block before it ships, enforce it across every account, and contain incidents and runaway spend, with a person approving every action. Early access [Book a 30-min call with the founders ](https://calendar.app.google/URDL4Q2mMJMnoSJK6)[Tell us your problem](https://f200.ai/#contact)[Request Sternguard early access](https://f200.ai/?interest=product.cloud-governance&intent=early-access#contact)How a guardrail goes live - Write as code - Prove the impact - Enforce org-wide - Contain incidents Every incident becomes a new guardrail ## Why teams choose it ### Stop incidents, not chase them Guardrails across the organisation remove whole classes of risk, instead of producing more findings. ### Cap the bill A spend cap stops new resource creation when a budget is breached. No overnight surprise from a leaked key or a runaway agent. ### Say yes to AI agents Every agent that touches AWS gets a permission ceiling, attribution and a way to stop it, at the AWS control plane. ### Pass audits faster Evidence comes from live policy state, mapped to frameworks. ### SecOps without hiring A built-in AI security engineer triages, investigates and drafts fixes. A person approves. ### A shorter security review It runs in your AWS account and your security data stays there. ### No lock-in Your policies live in your Git. You keep them whatever you decide. ### Built on AWS, not instead of it It uses the AWS detection, findings and access services you already pay for. ## Prevent and contain, across the organisation Most tools find and report, one team or account at a time. This one proves a fix, enforces it across the whole AWS Organization and contains what gets through. Placement by category is our own qualitative read, not measured data. ## Who it is for AWS Organizations with many accounts and a landing zone, run by a small platform or security team. The strongest fit is teams already running AI agents on AWS. | Who | The pain | What they get | | --- | --- | --- | | Security leaders | Too many findings to fix; board questions about AI agents. | Preventive controls across the organisation, AI agents under a ceiling, evidence ready for audit. | | Platform and cloud teams | A policy change could break production; policies kept by hand. | Policies as code in Git, impact checked before they are attached, staged rollout. | | Finance and FinOps | Surprise bills, a leaked key mining crypto, runaway agents. | A hard spend cap that stops new resources, not just an alert. | | CTOs without a SecOps team | No headcount for security operations. | An AI security engineer on the team; a person approves every action. | ## What it does Cloud governance and AI SecOps: guardrails in Git, enforced across your cloud organisation, with risky-access containment and compliance evidence. AWS today. Google Cloud, Azure and Oracle Cloud next. ### Guardrails defined in Git and enforced across your cloud organisation Written as code, synced between Git and AWS, and checked in your CI before anything is attached. ### Risky-access detection with time-boxed containment A compromised role or agent is contained; releasing it takes more than one person. ### Compliance evidence Scorecards and evidence from live policy state, mapped to frameworks. ### AI-agent governance Each agent that touches AWS gets its own permission ceiling, attribution and containment. ### Cost guardrails A spend cap on resource creation, alongside budgets, anomalies and commitments. ## How it works A guardrail reaches your accounts only after its impact is known and a person has approved it. An incident takes a fast path to containment, and its fix becomes a new guardrail. ### Change path Write the guardrail as code; an impact simulation shows who and what it would block; a person approves; it runs in shadow, then is enforced across the organisation; every change is read back, and an unconfirmed one is reported as such, never silently retried. ### Incident path A signal from the AWS detection you already run; the AI security engineer explains the attack path and the smallest fix; the session is denied or the role or agent quarantined; releasing it takes more than one person; the fix goes back to Git. ## Safe by design ### A person approves every action Autopilot is off by default, and every write starts as a dry run. ### Sternguard acts and keeps the evidence Every action is recorded with its evidence; advice is never presented as an action taken. ### Your data stays in your account Only the licence status reaches F200. ### It never locks you out If the licence check can't be reached, it keeps running. ### Limited to what you allow It changes only what its roles in your account permit, with viewer, operator and admin access. ### Your agents can use it safely Over MCP, with changes off unless you enable them and credentials redacted. ### Honest when a source is off An AWS source that isn't enabled is reported as not measured, never as a clean result. ### Your policies stay yours They live in your Git, whatever you decide. ## It runs in your AWS account You deploy it into your management or a delegated-admin account. It reads the AWS signals you already run, keeps policies in sync with your Git, and applies guardrails, containment and the spend cap to every account in your organisation. ## Built on the AWS services you already run It uses each one if it is enabled and never requires it. | AWS service | What it does with it | | --- | --- | | AWS Organizations | Service and resource control policies, simulated and attached. | | IAM Access Analyzer | Policy proofs, unused access, and right-sizing you can apply and revert. | | GuardDuty, Detective, CloudTrail | Attack sequences, investigations and containment triggers. | | Security Hub, Inspector | Findings combined into fewer, higher-value fixes. | | AWS Budgets, Cost Explorer | Budget actions, anomalies and the spend cap. | | Amazon Bedrock AgentCore | Posture and permission ceilings for your AI agents. | ## A proof of concept that ends in enforcement In a sandbox organisational unit of your AWS Organization, with your management or a delegated-admin account and a Git repository for policies. ### Discover Your accounts, organisational units and pains; one guardrail and one incident scenario chosen. ### Install Into your account; your Git connected; the signals you run light up. ### Prove and shadow The guardrail simulated, then run in shadow. ### Enforce and contain The guardrail enforced with read-back; a test role contained and released; a spend cap set. ### Read out An evidence report of what was proven, enforced and contained. ## Related services ### [SecOps & cloud governance](https://f200.ai/services/secops) Stop risky access before it becomes a breach: guardrails defined in Git and enforced across your cloud organisation, with access risk detection, time-boxed containment and compliance evidence. ### [FinOps](https://f200.ai/services/finops) Know where every dollar goes and stop the waste: cost reviews, budgets and guardrails, commitments and rightsizing, and cost anomaly response, across the clouds we work with. ## Frequently asked questions ### Which clouds does it cover? AWS today. Google Cloud, Azure and Oracle Cloud next. ### Could it break production? Every change is simulated, run in shadow mode, approved by a person and read back after it is attached. ### Does our security data leave our account? No. It runs in your AWS account; only the licence status reaches F200. ### Can an AI change our AWS on its own? No. The AI security engineer recommends; a person approves every action, and every action is recorded with its evidence. Autopilot is off by default. ### We already manage our policies with Terraform. Keep it. The policy checks run as a step in your CI. ### Can we use it now? Sternguard is in early access. Request early access, or talk to an engineer about the services it powers: SecOps & cloud governance and FinOps. ### Do you publish prices? No. Scope and commercial terms are agreed with you. ### Can my AI assistant read this page? Yes. This page is ordinary HTML that needs no AI call, and it is also served as Markdown. Your assistant can read the [published catalog](https://f200.ai/content/catalog.json) or connect through [F200.ai’s MCP interface](https://f200.ai/agents) and retrieve this offering by its stable identifier: product.cloud-governance. ## Start with the problem. We’ll start with a conversation. [Book a 30-min call with the founders ](https://calendar.app.google/URDL4Q2mMJMnoSJK6)[Tell us your problem](https://f200.ai/#contact)[Request Sternguard early access](https://f200.ai/?interest=product.cloud-governance&intent=early-access#contact) Source: https://f200.ai/products/shiftyard [F200.ai](https://f200.ai/)[Products](https://f200.ai/products)Shiftyard + YardBridge # Governed delivery for coding agents, under your rules. An open-source software factory for coding agents, in pre-release, on your own machines, that governs their delivery from task to landing: every tool call passes a policy gate, a person approves what matters, budgets cap spend, and work lands only through a batch you approve. Open source · pre-release [Book a 30-min call with the founders ](https://calendar.app.google/URDL4Q2mMJMnoSJK6)[Tell us your problem](https://f200.ai/#contact)[Get notified](https://f200.ai/?interest=product.software-factory&intent=notify&tier=0#contact)[Request YardBridge early access](https://f200.ai/?interest=product.software-factory&intent=early-access&tier=1#contact)How it works - Task - Policy gate - Checks pass - Approved landing Governed from task to landing ## The problem - Agents are fast, but delivery isn't: work in progress piles up, reviews become the bottleneck and nothing is auditable. - Agents hold your credentials and act on your machines, and nobody decides what they may run. - An agent can spend a budget overnight, and nobody sees it until the bill. ## Why teams choose it ### Governed delivery, end to end Your policy, approvals and budgets govern every step, from the task to the landing. ### Every tool call is checked Against your policy before it runs: allowed, denied, or put to a person. ### A person approves what matters An approval is bound to the exact command it was given for. ### Spend is capped Budgets hold each turn and each agent to what you allow. ### Nothing ends half-done Your checks must pass before a turn ends, in a fresh checkout. ### Governed landing Pull requests merge only in a batch a person approves, in order. ### Unattended, without collisions Agents run on their own and pick up where they left off, each in its own workspace; overlapping file claims are refused. ### Evidence for every step Gate decisions, approvals and verdicts are kept as the evidence that delivery stayed governed, with credentials redacted. ## Who it is for | Who | The pain | What they get | | --- | --- | --- | | Developers running agents | Agents need babysitting, overspend and collide on files. | Unattended runs that resume, budgets and isolated workspaces. | | Engineering leads | Reviews are the bottleneck and nothing is auditable. | Governed delivery: checks before a turn ends, approved landing, and the evidence of both. | | Security-minded operators | Agents hold credentials and act on the host. | Credentials stay on the machine; every tool call passes the gate. | ## What it does Shiftyard is an open-source software factory for coding agents, in pre-release: governed delivery on your own machines. YardBridge, its paid organisation layer, is in early access. ### Runs coding agents on your own machines On your laptop, a Mac mini or a cloud machine you run. ### Governance controls over every delivery flow: policy, approvals and budgets One policy gate for every tool call, approvals bound to the command, budgets per turn. ### A human approves what matters Gated commands, agent prompts, policy changes and every landing batch. ### Fleet view, policy as code and outcome KPIs for the whole organisation ## How it works Every change goes through the same flow, and a person decides what lands. ### What a person approves Commands the policy puts to a person, prompts from an agent, policy changes, configuration the factory did not write itself, and every landing batch. ### The evidence Each gate decision, approval, review verdict, landing and budget turn is kept in an append-only log, every entry chained to the one before: the proof that delivery stayed governed. ## Safe by design ### Your credentials stay on your machine Agent vendor logins are never read; secrets are encrypted in the system keyring. ### Local only The console and its interface listen only on your machine and need a token. ### One outbound path It fails closed and records only what it sent, never the content. ### Enforced on the host The policy gate runs on your machine, the same way every time. ## It runs on your machines Your agents, your repositories and your approvals stay where your work is. The organisation layer adds the view across every developer's factory. ## YardBridge, for the whole organisation YardBridge is the paid organisation layer, in early access. ### Fleet view Every developer's factory, seen as one organisation. ### Policy as code Distributed to every developer's factory. ### Outcome metrics What was delivered, not how many pull requests were opened. ### A visual SDLC flow builder Draw your delivery process. ### Organisation memory and context What the organisation knows, available to every factory. ## Tiers | | Shiftyard | YardBridge | | --- | --- | --- | | Status | Open source · pre-release | Early access | | For | Each developer | The whole organisation | | Cost | Free | Paid; scope and terms agreed with you | | What you get | The software factory for coding agents, run on your own machines. | The paid organisation layer: fleet view, policy as code distributed to every developer's factory, and outcome KPIs. | ## Related services ### [Software Factory Integration](https://f200.ai/services/software-factory-integration) Integrate an AI-assisted software factory into your established S-SDLC, under governance controls that span it: delivery stages, security controls, approvals, policies and audit evidence. ## Frequently asked questions ### Can we install Shiftyard today? Not yet. Shiftyard is in pre-release. Ask to be notified when it is public. ### Which agents does it run? Coding agents such as Claude Code and Codex, each under your policy, approvals and budgets. ### Can an agent merge on its own? No. Pull requests land only in a batch a person approves. ### Can you fit it into our delivery process? Yes. Software Factory Integration fits AI-assisted delivery into your existing SDLC, under governance controls that span it: its security controls, approvals and policies. ### Do you publish prices? No. Scope and commercial terms are agreed with you. ### Can my AI assistant read this page? Yes. This page is ordinary HTML that needs no AI call, and it is also served as Markdown. Your assistant can read the [published catalog](https://f200.ai/content/catalog.json) or connect through [F200.ai’s MCP interface](https://f200.ai/agents) and retrieve this offering by its stable identifier: product.software-factory. ## Start with the problem. We’ll start with a conversation. [Book a 30-min call with the founders ](https://calendar.app.google/URDL4Q2mMJMnoSJK6)[Tell us your problem](https://f200.ai/#contact)[Get notified](https://f200.ai/?interest=product.software-factory&intent=notify&tier=0#contact)[Request YardBridge early access](https://f200.ai/?interest=product.software-factory&intent=early-access&tier=1#contact) Source: https://f200.ai/products/kanerva [F200.ai](https://f200.ai/)[Products](https://f200.ai/products)Kanerva # Your knowledge. One shared memory. A second brain for your people and AI agents. Connect your documents, conversations, records and other knowledge, or upload it directly. It ingests what you choose so useful context stays available across tools, people and sessions. Coming soon, being rewritten in Rust and planned as open source. Open source · coming soon [Book a 30-min call with the founders ](https://calendar.app.google/URDL4Q2mMJMnoSJK6)[Tell us your problem](https://f200.ai/#contact)[Get notified](https://f200.ai/?interest=product.engineering-memory&intent=notify#contact)How it works - Connect or upload - Ingest with sources - Retrieve knowledge - Use shared context Institutional knowledge compounds ## The problem - The answer exists somewhere: a document, a conversation, a record or someone's experience. - Every new person, task or AI session needs the same context explained again. - Changing tools or losing a team member means losing part of what you know. ## Many sources. One institutional memory. You choose the sources. The memory keeps useful knowledge with its origins. People and MCP-compatible agents draw relevant context from the same memory, wherever the next task starts. Planned product · source examples, not a connector list What you connect or upload - Documents notes and knowledge bases - Conversations discussions and messages - Records decisions and background - Your uploads material you choose Kanerva Your institutional memory - Knowledge and context - Sources and evidence - Access boundaries Use the same memory Your people Find context and its sources Your AI agents Relevant context through MCP New information + accepted correctionsContext for the next task ## Ask about what you already know Illustrative questions for the planned product. The answer depends on the information you connect and the access you allow. ### Why did we choose this approach? Find the discussion, the reasons behind the decision and the original material that supports it. ### What do we know before this customer call? Bring together relevant notes, previous conversations and agreed next steps. ### What should a new teammate know? Find the practices, background and decisions that usually take repeated explanations to pass on. ## Who it is for | Who | The pain | What they get | | --- | --- | --- | | Teams with scattered knowledge | Information lives in many tools and people's heads. | Shared memory from the sources they choose to connect. | | People working with AI agents | Each task requires explaining the same context again. | Knowledge that remains available across sessions and tools. | | Organisations preserving expertise | Context disappears when people change roles or leave. | Institutional knowledge kept with its sources and access boundaries. | ## What it does A second brain for people and AI agents. Ingest the knowledge you connect or upload, keep it with its sources, and use the same memory across tools and sessions. Coming soon. ### Ingests connected sources and uploaded information Connect the knowledge you choose or upload material directly. Specific connectors and formats will be documented at release. ### Keeps knowledge with its sources Keep information, context and decisions attached to their origin and supporting evidence. ### Serves memory to people and AI agents Find institutional knowledge as a person or let an MCP-compatible agent retrieve relevant context from the same memory. ## From scattered information to a grounded answer Illustrative example: a question about a regional launch brings back a planning note, a customer conversation and an approved decision. Those sources explain the launch scope and when it should be reviewed. This shows the intended workflow, not a live product result or customer data. Illustrative example · not customer data or a live product result The question Why did we choose a regional launch? Asked by a person or an AI agent Relevant knowledge - Planning note The proposed launch scope - Customer conversation Needs and expectations - Approved decision The reason and review point An answer you can check Start with a region the team can support. Review the scope after the first launch. Follow the answer to its sources Planning note · Customer conversation · Approved decision ### Connect or upload Choose the information you want in memory: documents, conversations, records, knowledge bases or other material. Connector and format availability will be documented at release. ### Ingest with context Keep useful knowledge, its origin and the evidence behind it together, with boundaries on who can use it. ### Retrieve what matters Ask a question or start a task. People and agents use the relevant knowledge and can follow it back to its sources. ## Keep the material and the meaning ### The original sources Documents, conversations and records give the memory its grounding. An answer should lead back to the information behind it. ### What the organisation knows Decisions, practices, lessons and context make that information useful beyond the moment it was created. ### Relevant context for the next task Retrieve the knowledge that helps with the question in front of you, rather than re-explaining the organisation's history each time. ## Knowledge that carries forward The goal is a memory you can keep building: new sources add context, and accepted corrections update what people and agents find next time. ### Add what you learn Bring new information into the same memory so the next conversation can build on it. ### Correct what has changed Keep corrections with their basis and evidence. A changed decision should not leave yesterday's answer looking current. ### Change tools, keep the context The memory belongs to you. MCP gives compatible agents a way to use it without rebuilding your knowledge for each tool. ## Your memory. Your boundaries. Planned product · memory under your control Intake You choose what goes in Selected connections and uploads feed your memory. Access Private knowledge stays scoped Widening access takes a review. Credentials are redacted when stored. Outbound Check what leaves Text fails closed without a deny list, is scrubbed, and only its fingerprint is logged. ### Choose what goes in You choose the connected sources and uploaded material. Its service listens only on your machine. ### Choose who can use it Private knowledge stays scoped; widening its access takes a review. ### Check what goes out Outbound text fails closed without a deny list, is scrubbed, and only its fingerprint is logged. Credentials are redacted when stored. ### Keep data as data Instructions inside connected documents or messages are information, never commands. ## Why Kanerva? The name honours Pentti Kanerva, whose Sparse Distributed Memory was published by MIT Press in 1988. His theory explores associative memory: how a partial cue can retrieve relevant experience through similarity. ### Start with a cue, find the context You may remember a topic or a reason without remembering the exact document. The product idea is to connect that cue to relevant knowledge and its sources. ### An institution remembers People change roles and agents start fresh sessions. Knowledge should remain available to the organisation. The research inspires this goal; it is not a claim that the product implements the book's memory architecture. [Pentti Kanerva: Sparse Distributed Memory — MIT Press](https://mitpress.mit.edu/9780262514699/sparse-distributed-memory/) ## Related services ### [Company Memory](https://f200.ai/services/frontier-engineering/company-memory) An AI brain for your company: context engineering that keeps decisions with their sources, from your documents, runbooks and code, and serves them to your people and agents. ## Frequently asked questions ### Can we install it today? Not yet. Kanerva is open source and coming soon. Until it is public, Company Memory is delivered as a service. ### What can we connect or upload? The scope is the knowledge you choose: documents, conversations, records, knowledge bases and other information. Multiple connectors and uploads are planned; specific supported connectors and formats will be documented at release. ### How do agents use it? Over MCP: compatible agents retrieve relevant knowledge and its sources from the same memory. ### Does the memory grow automatically? It grows through the information you choose to ingest and the corrections accepted into it. That means richer stored context, rather than a promise that every interaction improves an AI model. ### How is sensitive information handled? Access scopes limit who can use private knowledge. Outbound text is checked against a deny list, and credentials are redacted when stored. ### Do you publish prices? No. Scope and commercial terms are agreed with you. ### Can my AI assistant read this page? Yes. This page is ordinary HTML that needs no AI call, and it is also served as Markdown. Your assistant can read the [published catalog](https://f200.ai/content/catalog.json) or connect through [F200.ai’s MCP interface](https://f200.ai/agents) and retrieve this offering by its stable identifier: product.engineering-memory. ## Start with the problem. We’ll start with a conversation. [Book a 30-min call with the founders ](https://calendar.app.google/URDL4Q2mMJMnoSJK6)[Tell us your problem](https://f200.ai/#contact)[Get notified](https://f200.ai/?interest=product.engineering-memory&intent=notify#contact) Source: https://f200.ai/products/tillerpin [F200.ai](https://f200.ai/)[Products](https://f200.ai/products)Tillerpin # Probability-grounded decisions under real-world uncertainty. A System-1 model for confidence-based, typed decisions in agent pipelines (yes/no, choice and relations), with open weights and documented training data. Coming soon [Book a 30-min call with the founders ](https://calendar.app.google/URDL4Q2mMJMnoSJK6)[Tell us your problem](https://f200.ai/#contact)[Get notified](https://f200.ai/?interest=product.decision-model&intent=notify#contact)How it is meant to work - Typed question - Estimate the odds - Act when likely - Uncertain to a person Acts on the odds, not a guess ## The problem - Agents ask big models small questions all day, and pay for every one in time and money. - Answers sound equally sure whether they are right or not, so nothing can route on them. - Nobody can say what a model was trained on, or rebuild it. ## How it is being built ### Decisions under real-world uncertainty Each decision is designed to carry its probability of being right, so agents act on the likely ones and pass the uncertain ones on. ### Human labels only No label comes from another model. ### Label quality measured first Labels are checked against blind re-labels before the test set is frozen. ### Data you can rebuild Every source is pinned, and the data rebuilds exactly. ### No leakage Related examples stay in one split, and the test set is frozen before any model is chosen. ### Clean licences Sources with unclear licences are kept out. ### Safe weight files Only safe formats; unsafe files are refused. ### Open by design A model card, data documentation and reproducibility manifests at release. ## Who it is for | Who | The pain | What they get | | --- | --- | --- | | Teams building agents | Big-model calls for small checks are slow and costly. | Fast typed decisions, each with the odds to route on. | | ML leads | A model whose data and labels are unknown can't be trusted. | Human labels and data that rebuild exactly. | | Compliance-minded buyers | Unclear licences and unsafe weight files. | Clean sources and safe formats only. | ## What it does A System-1 model for fast, typed decisions (yes/no, choice and relations), designed for calibrated decision-making in agent pipelines, with open weights and documented training data. Coming soon. ### Typed decisions: yes/no, choice and relations ### Open weights ### Documented training data ## How it is meant to work An agent asks a typed question; the model decides fast and says how likely it is to be right; likely decisions route the work, and uncertain or high-stakes ones go to a bigger model or a person. ## Why a System-1 model ### Fast decisions that steer slow reasoning It makes the quick, typed decisions while a large model does the slow reasoning, designed for calibrated, auditable decisions at lower cost. ## From sources to release This is the plan the release follows; nothing is released yet. ### The first decisions Evidence relations: does this evidence support, contradict, say nothing about, or leave open this claim. ### What “calibrated” means here Confidence that matches how often it is right; it is a design goal, measured before release. ## What we will publish These are commitments for the release, not results. ### A model card ### Training and data documentation ### Reproducibility manifests ### A licence ## Planned uses Examples of where it is meant to work. ### Routing ### Relevance filtering ### Review gates in agent workflows ## Related services ### [Fine-tuning and your own models](https://f200.ai/services/frontier-engineering/fine-tuning) Models adapted to your domain, from embeddings, rerankers and classifiers to judgment models, with dataset review, evaluation design and deployment guidance; evaluations decide what ships. ## Frequently asked questions ### How accurate or fast is it? We publish no numbers before the release. It is coming soon. ### Can we have our own decision model now? Yes, as a service: Fine-tuning and your own models builds judgment models for your domain, and evaluations decide what ships. ### Can my AI assistant read this page? Yes. This page is ordinary HTML that needs no AI call, and it is also served as Markdown. Your assistant can read the [published catalog](https://f200.ai/content/catalog.json) or connect through [F200.ai’s MCP interface](https://f200.ai/agents) and retrieve this offering by its stable identifier: product.decision-model. ## Start with the problem. We’ll start with a conversation. [Book a 30-min call with the founders ](https://calendar.app.google/URDL4Q2mMJMnoSJK6)[Tell us your problem](https://f200.ai/#contact)[Get notified](https://f200.ai/?interest=product.decision-model&intent=notify#contact) Source: https://f200.ai/solutions [F200.ai](https://f200.ai/)Solutions # Three AI outcomes, one cloud foundation. Each outcome has a fixed-scope way to start. Our services deliver it; our products power it where noted. [Book a 30-min call with the founders ](https://calendar.app.google/URDL4Q2mMJMnoSJK6)[Tell us your problem](https://f200.ai/#contact)[Explore Shiftyard](https://f200.ai/products/shiftyard)One cloud foundation under every outcome - AI workforce - Company intelligence - Software factory - Cloud foundation ## AI workforce AI workers that take on tickets, email, calls, automations and engineering tasks, with your people approving what matters, a company memory behind them and agent access governed across your cloud. - Where to start ### [AI workforce pilot](https://f200.ai/?interest=solution.ai-workforce&intent=start#contact) We pick one workflow with you, map how it runs today, and build an AI worker for it with human approval at the points you choose. Then: Extend the AI workforce to further workflows, with Company Memory behind it. - A working AI worker on one workflow, in your account - Its evaluation against how the work runs today - A decision on what to extend next ### [Tillerpin](https://f200.ai/products/tillerpin) Coming soon A System-1 model for fast, typed decisions (yes/no, choice and relations), designed for calibrated decision-making in agent pipelines, with open weights and documented training data. Coming soon. ### [AI workers](https://f200.ai/services/frontier-engineering/ai-workers) Service AI workers and AI engineers that take on repetitive work: automations, ticket, email and call handling, and engineering tasks, with your people approving what matters. ### [Company Memory](https://f200.ai/services/frontier-engineering/company-memory) Service An AI brain for your company: context engineering that keeps decisions with their sources, from your documents, runbooks and code, and serves them to your people and agents. ### [SecOps & cloud governance](https://f200.ai/services/secops) Service Stop risky access before it becomes a breach: guardrails defined in Git and enforced across your cloud organisation, with access risk detection, time-boxed containment and compliance evidence. ## Company intelligence AI that knows how your business works: a company memory that keeps every decision with its source, and your own models, kept only when they win on your evaluations. Delivered in your account, so what it learns stays yours. - Where to start ### [Company AI readiness review](https://f200.ai/?interest=solution.company-ai&intent=start#contact) We review the knowledge, decisions and tasks your AI should learn from, the permissions and privacy rules on that data, and how success will be evaluated. Then: Build the first memory or model, kept only when it wins on your evaluations. - A design for your company memory and models - An evaluation plan that decides what ships - A scoped first build ### [Kanerva](https://f200.ai/products/kanerva) Open source · coming soon A second brain for people and AI agents. Ingest the knowledge you connect or upload, keep it with its sources, and use the same memory across tools and sessions. Coming soon. ### [Tillerpin](https://f200.ai/products/tillerpin) Coming soon A System-1 model for fast, typed decisions (yes/no, choice and relations), designed for calibrated decision-making in agent pipelines, with open weights and documented training data. Coming soon. ### [Frontier Engineering](https://f200.ai/services/frontier-engineering) Service Frontier AI built for your company: a company memory that keeps every decision with its source, your own models trained on your work, and AI workers, each evaluated before it ships. ### [Fine-tuning and your own models](https://f200.ai/services/frontier-engineering/fine-tuning) Service Models adapted to your domain, from embeddings, rerankers and classifiers to judgment models, with dataset review, evaluation design and deployment guidance; evaluations decide what ships. ### [Company Memory](https://f200.ai/services/frontier-engineering/company-memory) Service An AI brain for your company: context engineering that keeps decisions with their sources, from your documents, runbooks and code, and serves them to your people and agents. ## Software factory Coding agents inside your existing SDLC, under governance controls that span it (your stages, security controls, approvals and policies, with audit evidence for agent work), and your engineering memory served to the agents. - Where to start ### [Factory fit assessment](https://f200.ai/?interest=solution.ai-delivery&intent=start#contact) We map your S-SDLC stages, security controls, review gates and approvals against agent-assisted delivery, and choose the repository to pilot on. Then: Run the pilot, then roll the factory out team by team. - An integration design for your SDLC - The gates and policies agent work must pass - A pilot plan on one repository ### [Shiftyard + YardBridge](https://f200.ai/products/shiftyard) Open source · pre-release Shiftyard is an open-source software factory for coding agents, in pre-release: governed delivery on your own machines. YardBridge, its paid organisation layer, is in early access. ### [Kanerva](https://f200.ai/products/kanerva) Open source · coming soon A second brain for people and AI agents. Ingest the knowledge you connect or upload, keep it with its sources, and use the same memory across tools and sessions. Coming soon. ### [Software Factory Integration](https://f200.ai/services/software-factory-integration) Service Integrate an AI-assisted software factory into your established S-SDLC, under governance controls that span it: delivery stages, security controls, approvals, policies and audit evidence. ## Cloud foundation The governed, cost-controlled cloud your AI runs on: platform, reliability, guardrails and spend, with Cloud & DevOps, AI SRE & on-call, SecOps & FinOps, governance & compliance. Infrastructure as code, CI/CD and observability, service-level objectives and AI-assisted on-call, guardrails in Git and budgets that enforce themselves. - Where to start ### [Cloud governance and cost review](https://f200.ai/?interest=solution.cloud-foundation&intent=start#contact) We review your accounts, access, guardrails, reliability and spend across the clouds you run, and rank what to fix first. Then: Put the guardrails and budgets in place and run the platform with you. - Findings on risky access, reliability gaps and waste - The guardrails to define in Git - A prioritised plan ### [Sternguard](https://f200.ai/products/sternguard) Early access Cloud governance and AI SecOps: guardrails in Git, enforced across your cloud organisation, with risky-access containment and compliance evidence. AWS today. Google Cloud, Azure and Oracle Cloud next. ### [Cloud & DevOps](https://f200.ai/services/cloud-devops) Service Cloud and platform engineering on AWS, Google Cloud, Azure and Oracle Cloud (OCI): infrastructure as code, CI/CD, observability, and migrations, including between clouds. ### [AI SRE & on-call](https://f200.ai/services/sre) Service Fewer incidents and faster recovery: reliability engineering, service-level objectives, and on-call and incident response with AI assistance and your people in charge, across the clouds we work with. ### [SecOps & cloud governance](https://f200.ai/services/secops) Service Stop risky access before it becomes a breach: guardrails defined in Git and enforced across your cloud organisation, with access risk detection, time-boxed containment and compliance evidence. ### [FinOps](https://f200.ai/services/finops) Service Know where every dollar goes and stop the waste: cost reviews, budgets and guardrails, commitments and rightsizing, and cost anomaly response, across the clouds we work with. ## Frequently asked questions ### Which one fits me? Not sure which fits? Describe your goal on the home page; the site’s AI suggests the services, products and solutions, and you take them into your inquiry. [Describe your goal](https://f200.ai/#explore) ### How do we start? With the fixed-scope entry offer of the outcome you need: its scope and deliverables are listed above. Timing and commercial terms are agreed with you. ### Do you build for a specific industry? These pages describe outcomes, not industries. Each service and product also has its own page. ### Do you publish prices? No. Scope and commercial terms are agreed with you. ### Can my AI assistant read this page? Yes. This page is ordinary HTML that needs no AI call, and it is also served as Markdown. Your assistant can read the [published catalog](https://f200.ai/content/catalog.json) or connect through [F200.ai’s MCP interface](https://f200.ai/agents). ## Start with the problem. We’ll start with a conversation. [Book a 30-min call with the founders ](https://calendar.app.google/URDL4Q2mMJMnoSJK6)[Tell us your problem](https://f200.ai/#contact)[Explore Shiftyard](https://f200.ai/products/shiftyard) Source: https://f200.ai/how-we-work [F200.ai](https://f200.ai/)How we work # From first pilot to production, one partner. Built with AI, shipped by humans. Every engagement starts with a fixed-scope step, and engineers stay accountable from the first assessment to running what we built. [Book a 30-min call with the founders ](https://calendar.app.google/URDL4Q2mMJMnoSJK6)[Tell us your problem](https://f200.ai/#contact)[Explore Shiftyard](https://f200.ai/products/shiftyard)How an engagement runs - Assess - Build under controls and evals - Run and improve Accountable after go-live ## How an engagement runs ### Assess We start in your cloud account, from the outcome you need and the constraints you have. ### Build under controls and evals Governance controls and evaluations decide what ships, with a human approving what matters. ### Run and improve We stay accountable after go-live and keep improving what we built. ## One operating model, from pilot to production. ### Intent Humans set the intent and the policy agents work within. ### Agents Agents do the work, with every step traced for review. ### Gates Every change is validated; a failed check goes back to the agents. ### Production An engineer approves and releases the accepted result. ### Day 2 operations Self-healing DevOps, SecOps and FinOps. Customer bug reports and feedback loops. ### Humans People watch and steer every stage. Nothing ships unreviewed. ## What we hold to Your cloud, your data, your rules. ### Human approval where it matters ### Open source and open weights where we can ### Evaluations decide what ships ## We run on what we ship. Proof from this website itself. You can check each point. ### Every AI call on this site passes a cost cap. Each new AI feature lands switched off behind a feature flag and is turned on only once its evaluation is in. ### Every release passes an automated naming and claims gate before it deploys. It refuses a release whose pages, Markdown twins or agent endpoints show an internal name or a listed claim we cannot back, such as a certification, a price, a partner tier or a statistic. ### The site is readable by AI agents. Every page has a Markdown twin, the portfolio is published as JSON, and an MCP endpoint answers agents. - [Markdown index](https://f200.ai/index.md) - [catalog.json](https://f200.ai/content/catalog.json) - [MCP](https://f200.ai/mcp/server-card) ## Your agent is welcome here. The same facts, in the formats agents read. ### [For AI agents](https://f200.ai/agents) ### [Markdown index](https://f200.ai/index.md) ### [catalog.json](https://f200.ai/content/catalog.json) ### [MCP](https://f200.ai/mcp/server-card) ## Frequently asked questions ### Does an AI release to production on its own? No. Agents carry out the work, validation gates check it, and engineers ship the accepted result to production. ### Does everything run in our account? Each service page says where its work runs. We do not make it a blanket claim. ### Can my AI assistant read this page? Yes. This page is ordinary HTML that needs no AI call, and it is also served as Markdown. Your assistant can read the [published catalog](https://f200.ai/content/catalog.json) or connect through [F200.ai’s MCP interface](https://f200.ai/agents). ## Start with the problem. We’ll start with a conversation. [Book a 30-min call with the founders ](https://calendar.app.google/URDL4Q2mMJMnoSJK6)[Tell us your problem](https://f200.ai/#contact)[Explore Shiftyard](https://f200.ai/products/shiftyard) Source: https://f200.ai/company [F200.ai](https://f200.ai/)Company # The engineers behind your AI workforce. AI Workforce Factory: AI workers, your own company AI and coding agents in your delivery, built by engineers on a governed cloud. We work with AWS, Google Cloud, Azure and Oracle Cloud (OCI). [Book a 30-min call with the founders ](https://calendar.app.google/URDL4Q2mMJMnoSJK6)[Tell us your problem](https://f200.ai/#contact) ## Founders ### Anton Grishko Co-founder · Product & Engineering Anton has built and run infrastructure since 2005 and has worked as a DevOps architect for over ten years. In the Google Cloud unit of a large IT services firm, he led complex migrations of large enterprises to Google Cloud and spoke at Google events. Before that he led DevOps teams for enterprise and product companies, and he went on to serve as a chief architect. At F200.ai he leads product and engineering. ### Ivan Hilevych Co-founder · Business Development Ivan has spent over ten years helping tech startups and growing companies find engineering teams that deliver. He has led sales for R&D and DevOps services companies as Chief Sales Officer and Head of Sales, and managed strategic enterprise accounts at a Microsoft partner. He works relationship-first: an honest conversation about fit comes before any deal. At F200.ai he leads business development. ## The team behind F200.ai We have run production infrastructure since the mid-2000s, from telecom platforms and enterprise data centres to multi-cloud estates on AWS, Google Cloud and Azure. Between us: large enterprise migrations to Google Cloud, a cross-cloud migration of hundreds of microservices, DevSecOps and secure-SDLC programmes, SRE practices and cloud cost optimisation for retail, fintech, real-estate and enterprise software companies. More recently we have worked on GenAI solution architecture (RAG and knowledge bases, evaluation frameworks, guardrails and security for LLM applications) and agentic software delivery with human-in-the-loop controls, which is the practice behind our software factory. On the commercial side, we bring over ten years of building delivery partnerships with startups and growing companies. ### Cloud platforms and migrations - [Cloud & DevOps](https://f200.ai/services/cloud-devops) ### Security and governance - [SecOps & cloud governance](https://f200.ai/services/secops) ### SRE and operations - [AI SRE & on-call](https://f200.ai/services/sre) ### FinOps - [FinOps](https://f200.ai/services/finops) ### GenAI and agentic delivery - [Frontier Engineering](https://f200.ai/services/frontier-engineering) - [Software Factory Integration](https://f200.ai/services/software-factory-integration) ## More from F200.ai ### [Careers](https://f200.ai/careers) ### [News](https://f200.ai/news) ### [Blog](https://f200.ai/blog) ### [Contact](https://f200.ai/#contact) ## Frequently asked questions ### Who is behind F200.ai? The founders and the team described above. F200.ai is the brand of F200AI LLC. ### Can we talk to the founders? Yes. Book a 30-minute call with the founders, or describe your goal in the contact form and an engineer replies. ### Can my AI assistant read this page? Yes. This page is ordinary HTML that needs no AI call, and it is also served as Markdown. Your assistant can read the [published catalog](https://f200.ai/content/catalog.json) or connect through [F200.ai’s MCP interface](https://f200.ai/agents). ## Start with the problem. We’ll start with a conversation. [Book a 30-min call with the founders ](https://calendar.app.google/URDL4Q2mMJMnoSJK6)[Tell us your problem](https://f200.ai/#contact) Source: https://f200.ai/agents F200.ai / For AI agents # A front door for your agent. AI Workforce Factory: AI workers, company intelligence and coding agents built by engineers on a governed cloud. Read the same published facts and articles through a structured interface. [Book a 30-min call with the founders ](https://calendar.app.google/URDL4Q2mMJMnoSJK6)[Tell us your problem](https://f200.ai/#contact)[Explore the human interface](https://f200.ai/#explore) Live website example ### An assistant finds a service and prepares an inquiry. “We need help with incident response and on-call reliability.” - Discover the available tools. - Read the published SRE offering. - Prepare a brief for you to review. This scripted demonstration calls our real public MCP endpoint. It uses a fixed example, without model inference. Inquiry preparation sends no email and stores no contact details. Run the assistant example ## Start with the facts No model call or JavaScript is needed to read our company and offering information. Request a public page with Accept: text/markdown, or append .md to a service, product or editorial URL. - [Company overview in Markdown](https://f200.ai/index.md) - [Published offering catalog in JSON](https://f200.ai/content/catalog.json) - [Current machine reading index](https://f200.ai/llms.txt) - [Complete public text](https://f200.ai/llms-full.txt) - [Published articles, news and vacancies](https://f200.ai/content/editorial.json) ## Connect through MCP The remote endpoint is https://f200.ai/mcp. Inspect its live discovery response for supported tools and protocol compatibility. - [Server connection card](https://f200.ai/mcp/server-card) - [Experimental domain discovery](https://f200.ai/.well-known/ai-catalog.json) - [Current integration status](https://f200.ai/api/status) - [Current quality checks and individual results](https://f200.ai/content/quality.json) Domain discovery is experimental. A client may require you to add the endpoint explicitly. ## Explore, then act - Use get_company, list_offerings and get_offering to read company facts, solutions and offering status. - Use ask_website for a compact, cited answer. Request includeComposition only when you need a generated view. - Use search_content, list_editorial and get_editorial to find and read published articles. Inspect citations, publication dates and limitations. - Prepare an inquiry for the user to review. - Hand off to the browser contact form for the user to review and explicitly submit with consent. Public MCP never submits an inquiry. ## Know the boundaries The site’s AI selects from reviewed content; it does not invent prices, product availability or company claims. Generated layouts contain trusted components. Submitting an inquiry does not book a meeting, make a purchase or execute a product. The public website MCP is read-only and has no CMS administration or publishing tools. Inquiry preparation stores nothing and sends nothing. ## Explore the experience map as data. The [experience map](https://f200.ai/content/experience.json) connects the site’s navigation to published offerings, canonical pages and their MCP interactions. Use the same AI-backed view composition to select relevant content and an overview, comparison or roadmap. Inspect the returned source and offering IDs before following a recommendation. Agents can complete the discovery and inquiry-preparation journey through these structured operations. ## Built into the browser, too. On browsers that support the experimental WebMCP API, the page offers read-only portfolio and view-composition tools. Standard links, HTML and remote MCP remain available to other clients. WebMCP browser support is checked when JavaScript runs. Remote MCP and public documents work independently. ## Start with the problem. We’ll start with a conversation. [Book a 30-min call with the founders ](https://calendar.app.google/URDL4Q2mMJMnoSJK6)[Tell us your problem](https://f200.ai/#contact)[Explore the human interface](https://f200.ai/#explore) Source: https://f200.ai/privacy F200.ai / Privacy # Privacy policy How F200.ai handles personal data: what the website and our LinkedIn application collect, why, who processes it, how long we keep it, and your rights. [Book a 30-min call with the founders ](https://calendar.app.google/URDL4Q2mMJMnoSJK6)[Tell us your problem](https://f200.ai/#contact) Last updated: 22 October 2026. ## Who we are F200.ai is the brand of F200AI LLC. F200AI LLC is the controller of the personal data described here: the f200.ai website and the LinkedIn application F200.ai uses for its company page. To contact us about privacy, use the [contact form](https://f200.ai/#contact). ## What we collect and why We collect only what the website needs to answer you and to work well. You can read every public page without giving us any personal details. | What | Why | Legal basis | | --- | --- | --- | | Contact form: your name, email address, company (optional), the offerings you select and your message | To answer your inquiry and talk with you about it | Your consent, given when you confirm and send the form; and steps you ask us to take before a possible contract | | Text you type into the site's search or goal finder, and questions sent to our public MCP interface | To answer your question and find relevant pages | Our legitimate interest in answering the questions you ask us | | Usage analytics: pages you visit, links and buttons you use, how far you read, device and browser, approximate location and the page that referred you | To understand which content is useful and improve the site | Our legitimate interest in understanding how the site is used | | Technical data: IP address, browser headers and request details | To deliver the site, protect it against abuse (rate limits) and troubleshoot errors | Our legitimate interest in running a secure, working website | When you use search, the goal finder or our MCP interface, we remove email addresses, phone numbers, card and bank numbers, ID numbers, secrets and links with tokens before the text reaches a hosted model. If the text still looks personal after that, we do not send it. Names you enter in the contact form are never sent to a model; the form is stored, not analysed. Submitting the contact form does not book a meeting or make a purchase. The “Book a 30-min call with the founders” link opens Google’s booking page, where Google’s privacy policy applies. ## Cookies and similar technologies Our own code sets no cookies while you browse the site. Google Tag Manager loads Google Analytics 4 and Contentsquare when a page loads, and these services set their own cookies and similar identifiers to measure visits. You can block or delete them in your browser settings, or use Google’s opt-out browser add-on for Google Analytics. Our fonts are served from f200.ai, not from a third-party font service. ## Processors and third parties We use these service providers to run the website. They process personal data on our behalf, for the purposes described here. | Provider | What it does for us | Data | | --- | --- | --- | | Cloudflare | Hosts the website and its APIs, stores contact-form inquiries (D1 database), runs the AI search and model gateway (Workers AI, AI Search, AI Gateway), and keeps sampled request logs | Everything the site processes | | Google (Google Tag Manager and Google Analytics 4) | Usage analytics, loaded through a first-party address on f200.ai with IP concealment enabled | Usage analytics | | Contentsquare | Usage analytics, loaded through Google Tag Manager | Usage analytics | | An AI model provider | Runs the model that chooses which approved content to show for your question, reached through Cloudflare's AI Gateway with logging and caching turned off | Search, goal finder and MCP question text, after personal details are removed | We do not sell personal data, and we do not share it with anyone else unless the law requires us to. ## International transfers Our providers run global infrastructure. Your data may be processed outside your country, including in the United States and the European Union. ## How long we keep data | Data | How long | | --- | --- | | Contact-form inquiries | 90 days from when you send them, then deleted automatically | | Search, goal finder and MCP questions | Not stored by us: used to answer the request and then discarded | | Rate-limit records | When used, a one-way hash of your IP address, kept for a few minutes | | Aggregate usage counts (requests, results, errors, latency) | 90 days; they contain no text, IP addresses, cookies or visitor identifiers | | Analytics data | According to the retention settings of Google Analytics and Contentsquare | | Cloudflare request logs | A sample of about one request in ten, kept for a limited period set by Cloudflare | ## Your rights Depending on where you live, including in the European Economic Area and the United Kingdom, you have the right to: - ask what personal data we hold about you and get a copy; - have inaccurate data corrected; - have your data deleted; - restrict or object to our processing, including processing based on our legitimate interests; - receive data you gave us in a portable format; - withdraw your consent at any time, without affecting processing that took place before; - complain to your local data protection authority. To exercise any of these rights, use the [contact form](https://f200.ai/#contact). We answer within 30 days. ## Security The site is served only over HTTPS. Rate limiting uses your IP address only in memory or as a short-lived one-way hash. Personal details are removed from text before it reaches a hosted model, and model gateway logging is turned off for visitor requests. Credentials are kept in an encrypted secret store, never in source code, and administrative endpoints require authentication. ## Children The website is meant for businesses and is not directed at children. We do not knowingly collect personal data from children. If you believe a child has sent us personal data, use the [contact form](https://f200.ai/#contact) and we will delete it. ## Changes to this policy We update this page when the way we process personal data changes. The date at the top shows the latest change. ## LinkedIn company page content F200.ai uses a LinkedIn application registered to F200AI LLC to publish posts on the F200.ai company page, to read that page’s statistics, and to read and answer comments on its posts through LinkedIn’s official Community Management API. This section explains what the application reads, what it stores, and for how long. ### What the application does - Publishes posts on the F200.ai company page. Every post is written for F200.ai, reviewed by a person at F200.ai, and approved before it is published. The application never publishes anything that has not been approved. - Reads statistics for the F200.ai company page and its posts. These are totals that LinkedIn provides to page administrators: impressions, reactions, comments, reposts and follower counts. - Reads comments and reactions on F200.ai company posts. We show them to the people at F200.ai who answer comments, with the commenter’s name, headline and profile link. - Replies to comments as F200.ai. A person at F200.ai reviews and approves every reply before it is posted. The application never posts a reply that has not been approved. ### What the application does not do - It does not post on behalf of any individual member, and it does not post on any page other than the F200.ai company page. - It does not read members’ connections, messages or feeds, and it reads no profile details beyond the name, headline and profile link of people who comment on our posts. - It uses commenters’ details only to show and answer comments on our own posts. It never uses them for advertising, sales, recruiting, lead lists or a CRM, and never combines them with other data. - It does not sell LinkedIn data or share it with third parties. - It does not process customer data. Our posts are about our own work; they do not name customers, and we check every post for customer and personal details before it is approved. ### What we store | Data | Why | Where | | --- | --- | --- | | The text and image of each company post, and when it was approved and published | To keep a record of what F200.ai has published and to avoid repeating topics | Cloudflare (D1 database and R2 storage), the United States and the European Union | | The post's LinkedIn address (URL) | To match statistics to the post | Same | | The company page's own posts as LinkedIn returns them | To match published posts and their statistics to our records | Same | | Totals per post and per day: impressions, reactions, comments, reposts, new followers | To learn which topics are useful to our readers | Same | | Comment text and other members' reactions on our posts | To show comments to the person who answers them | Same | | Commenters' name, headline and profile link | To show who wrote a comment | A short-lived cache only; never stored in the database | | LinkedIn member IDs and comment IDs | To link our replies to the comments they answer | Cloudflare (D1 database), the United States and the European Union | | Our own replies, and when they were approved and posted | To keep a record of what F200.ai has said in public | Same | | The access token LinkedIn issues to the application | To call the API on behalf of the F200.ai company page | An encrypted secret store; never in logs, messages or source code | ### How long we keep it - Our records of our own posts (text, image, approval and publish times): 365 days. - The company page’s own posts as read back from LinkedIn: 6 months. - Statistics totals for the page and its posts: 365 days. - Comment text and other members’ reactions: at most 48 hours. - Commenters’ name, headline and profile link: cached for at most 24 hours, never stored. - Member IDs and comment IDs: 365 days, the same as our post records. - Our own replies: 365 days. - Access tokens: until they expire or the application is disconnected, whichever comes first. They are deleted when the application is disconnected. - When a post is deleted from the company page, we delete its stored statistics within 30 days. ### Permissions the application asks for - w_organization_social and r_organization_social: publish posts and replies as F200.ai, and read the page’s posts, comments and reactions. - w_organization_social_feed and r_organization_social_feed: post and read comments on the page’s posts. - rw_organization_admin: confirm the connected person administers the F200.ai page, and read page and follower statistics. The application asks for no permission to post as, or read, an individual member’s profile (no w_member_social). ### Your choices - A company page administrator can disconnect the application at any time in LinkedIn’s settings. The application then stops reading and posting immediately. - To ask what we hold, or to ask us to delete data, use the [contact form](https://f200.ai/#contact). We answer within 30 days. ## Start with the problem. We’ll start with a conversation. [Book a 30-min call with the founders ](https://calendar.app.google/URDL4Q2mMJMnoSJK6)[Tell us your problem](https://f200.ai/#contact) # Explore F200.ai with your AI assistant Published: 2026-10-07T21:46:48.799Z Source: https://f200.ai/news/explore-f200-with-your-ai-assistant You can explore F200.ai through your AI assistant as well as your browser. Our public website provides a structured offering catalog, Markdown pages and a remote Model Context Protocol (MCP) endpoint. ## Start with the published facts Visit our [guide for AI agents](https://f200.ai/agents) for connection details and supported interactions. Assistants can read company information, explore services and products, and find published articles through the public endpoint at https://f200.ai/mcp. The [offering catalog](https://f200.ai/content/catalog.json) and [machine reading index](https://f200.ai/llms.txt) are also available directly. These give assistants access to the same approved information that visitors read on the website. ## Read our engineering insights Published articles cover software factories and governed coding-agent workflows. Explore the [blog](https://f200.ai/blog) in your browser, or use the editorial tools described in the agent guide to find and read articles through MCP. ## Prepare a conversation An assistant can help you explore relevant offerings and prepare an inquiry. You review and submit it through the website’s [contact form](https://f200.ai/#contact). The public MCP endpoint does not submit inquiries or administer the CMS. Start with the [agent guide](https://f200.ai/agents), or browse our [services](https://f200.ai/services) directly. # DevOps Engineer Published: 2026-10-07T21:44:20.060Z Source: https://f200.ai/careers/devops-engineer F200.ai is looking for a DevOps Engineer to help build dependable cloud infrastructure and delivery workflows for AI and software engineering projects. ## What you’ll work on - Build and improve infrastructure as code and repeatable environment setup. - Automate CI/CD pipelines, deployments and rollback procedures. - Operate cloud infrastructure and containerized services with a focus on reliability. - Improve monitoring, alerting, incident response and operational documentation. - Work with engineers to strengthen security, access controls and cloud cost visibility. ## What we’re looking for - Practical experience with cloud infrastructure, Linux and networking. - Experience with infrastructure as code, CI/CD and containers. - Confidence troubleshooting production systems and explaining what you find. - A habit of automating repetitive work and documenting decisions. - Interest in the infrastructure needs of AI systems and software factories. Experience with Kubernetes, Terraform, observability or platform engineering is welcome. Tell us about the tools you’ve used and the systems you’ve helped improve. ## Apply Use our [contact form](https://f200.ai/#contact) and start your message with “DevOps Engineer application”. Include a link to your CV or professional profile, a short example of relevant work, your location and your availability. We’ll discuss role scope and working arrangements directly. # Inside Shiftyard: a governed software factory for coding agents on your own machines Published: 2026-10-07T20:17:09.826Z Source: https://f200.ai/blog/inside-shiftyard-governed-software-factory-for-coding-agents ![Overhead harbour chart titled Shiftyard, with a dock building, four terminal-equipped berths, and a magenta route from work cards through a gatehouse to a harbour-mouth junction.](https://f200.ai/media/editorial/35301e25e24a7c5855daa9b9319ec19c145d56859aac0d501b21c750f9ebfcad.webp)Work follows a shared course through the Shiftyard harbour. Coding agents are good enough now that the hard part is no longer getting one to write a change. The hard part is running ten of them at once, on your own subscriptions, against real repositories, without one of them force-pushing to main, leaking a credential into a prompt, or quietly merging a pull request nobody reviewed. Shiftyard is the software we built to do that for ourselves. It is a daemon that runs unmodified coding-agent CLIs (Claude Code and Codex today) on machines you own, and wraps every one of them in a queue, leases, a policy gate, budgets, verification and a merge train. Since 5 October 2026 our own engineering work, including most of Shiftyard's own commits, has run on it. This post is a long, technical tour: the architecture, how a command gets allowed or refused, how two agents are kept from writing over each other, how a change travels from a queue item to a merged pull request, how the memory subsystem and its models are being selected, what we test and what we have measured. It also says plainly what is built, what is still in review, and what is only planned. Status. Shiftyard is pre-release: there is nothing to install yet. The code is licensed Apache-2.0 and the public repository is coming soon. Everything below describes the code as of early October 2026 on macOS hosts. ## 1. Why we built it A single coding agent in a terminal is a solved workflow. A team of them is not. Once you run more than a handful in parallel you meet the same failures over and over: - Shared state. Two agents claim the same ticket, or both rebase the same branch, or one writes after its claim has expired. - Unbounded actions. An agent that can run git push --force, terraform destroy or gh pr merge will, eventually, run it at the wrong moment. - Credentials. Vendor logins, cloud keys and tokens drift into prompts, logs and model context. - Verification theatre. An agent says the tests pass. Whether they ran, on which commit and with which files changed is another question. - Capacity. Subscriptions have usage windows, laptops have RAM and thermal limits, and a resumed session costs less than a fresh one. - Memory. Every new session re-derives what the last one already worked out. We had been running an earlier internal orchestration platform for this. Shiftyard is its rewrite: one Rust daemon per host, with every backend service native inside it, built around the lessons from operating the first one. ## 2. Principles Four principles are written into the project's README, and most design decisions trace back to them: - Your credentials stay on your machine. You sign in to each agent through its vendor's own login flow. Shiftyard never reads, stores or forwards those credentials. - One agent by default. A builder plus QA pair is an opt-in verification step, not the baseline. - Deterministic enforcement. Policy gates, sandboxing and budgets run on the host. They do not depend on the agent's cooperation. - Works offline. Local work never depends on the cloud. Two engineering rules follow from the third principle and shape the whole codebase: - Pure domain cores. The gate, leases, the work state machine, flows, budgets, capacity, the balancer and the model router are pure crates: no async runtime, no I/O and no clock. Time is passed in. That makes every rule property-testable and replayable. - One writer. A single SQLite writer thread owns every SQL statement; async code never writes to the database directly. Concurrency is three sanctioned patterns only: actor tasks with channels, the writer thread, and cancellation tokens for shutdown. ## 3. One host, end to end ![Host enclosure containing a daemon with API, scheduler, gate, store, land, and egress modules above three sandboxed terminal seats with lock icons and arrows to the gate, plus one egress exit.](https://f200.ai/media/editorial/ca14a224bf320507d903ddea4ead4183dad51fa5dfabee9a6ea535bc9af4f6e8.webp)One host contains the daemon, sandboxed seats, and a single egress path. A yard is one Shiftyard install: the daemon on one host and everything it runs. A crew is a named group of pods working toward one purpose. Pods organise related seats, and a seat is a durable position with a role and an address; the agent session in it can change. ![A macOS host contains a single daemon with eight modules and isolated seats. Operator traffic enters the API over loopback, hooks wait on the policy gate, bare-mirror objects feed each clone, and only redacted text exits through the egress sanitizer.](https://f200.ai/media/editorial/81025b7dd1082cd358addfe966a11cb82fd7e0ddec80dfb2707585e76a422ebd.webp)One host contains the daemon, isolated seats, and a single sanitized path out. The daemon exposes two listeners and nothing else: an operator listener on loopback (admin token or session cookie, browser defences, the embedded web UI, server-sent event streams) and a Unix socket for seats (per-seat tokens, daemon user only). There is deliberately no non-loopback listener, no TLS termination and no CORS. The local API is a typed RPC service of 94 methods, served as JSON or binary, with every schema change gated by a breaking-change check. ## 4. Seats: running unmodified agent CLIs Shiftyard does not fork or patch the agents. It runs the vendor's own CLI and controls it from the outside, through the same surfaces a careful human would use: the terminal, the CLI's hook system and its configuration. The launch plan. Every launch, resume and wake recomputes a launch plan as a pure function of the crew spec, the policy and the seat's state. It is never stored as truth; it is written to disk at mode 0600 just before launch, for the record. The PTY holder. The agent runs inside a small holder process that owns its pseudo-terminal. The daemon talks to the holder over an authenticated socket with a length-prefixed protocol that supports the current and previous version, so the daemon can be upgraded while seats keep running. Input is typed only as named keys or bracketed paste. Reading the screen. Detection reads the rendered screen, not the byte stream. We chose the terminal model with a spike that replayed real recorded sessions against a reference emulator (section 14): coding-agent TUIs draw spaces with cursor moves and put non-breaking spaces after their prompt glyph, so pattern-matching raw output is not reliable. Fenced stops. Every stop is fenced to a launch id and a generation. Settlement proves that the agent's process id, start time and process group are gone before a seat is considered stopped, so a late signal can never hit a newer launch. Claude Code. Each seat gets its own settings file with hooks and a status line, its own account directory and a private MCP configuration loaded in strict mode, so account-level MCP servers never leak into a seat. Hooks call back into the daemon over a private socket, bound to the launch nonce. PreToolUse waits for the gate's answer and fails closed. Until a session-start event proves which session is running, every tool call is denied. A usage-limit menu is only ever answered "stop and wait". A resume never silently becomes a fresh start; only the recycler starts fresh, deliberately, with a recovery packet. Codex. Each seat gets its own CODEX_HOME and a per-seat profile with hooks that route session start, prompt submit and tool calls to the gate. A deny or ask returns exit code 2. The account's own configuration is checked against an allowlist of keys pinned to one CLI version; account-level hooks, rules or skills refuse the launch rather than being silently stripped. Dangerous bypass flags are banned outright, and a resume first checks that the rollout exists and that no other writer holds it. Credentials. The account registry only probes identity: which email a Claude account belongs to, and whether a keychain item exists. The Codex driver is not allowed to open the credentials file at all. Other agents. An OpenCode driver exists (two sandboxed processes: a pinned server and an attached TUI, every permission request routed to the gate, and the daemon re-reading the agent's own store every second to detect rules it did not set). It is in review, not yet composed into the running daemon. Support for further CLIs exists only as offline interface probes. ## 5. The policy gate ![Terminal commands pass through parse and classify stages into a rule ladder that branches to a large navy DENY bin, a medium slate ASK bin, and a small magenta ALLOW bin.](https://f200.ai/media/editorial/a4b148d0dbe69acac439837a953157f3a83638584e0aac8ef7afac9068bd3ad8.webp)The policy gate lets the most restrictive rule determine the outcome. Every shell command an agent wants to run goes through the gate before it runs. The gate is a pure function: no clock, no store, no network and no model. ![Five policy stages parse command text, classify typed action kinds, apply eight first-match rules, combine outcomes as DENY over ASK over ALLOW, and atomically record authority and consume a grant in the hash-chained audit.](https://f200.ai/media/editorial/2c9f940fe5385723438932f0a5d3eb59733d290448137291a16b38bea2d43644.webp)The policy gate fails closed and records decisions with their authority. A few details matter more than they look: - Obfuscation fails closed. Command substitution the parser cannot resolve, continuation tricks and a handful of grammar edge cases are marked opaque on purpose. Only a person can allow an opaque action. - Protected refs. main and master are always protected, in any spelling and case. Writes into .git/ or hook directories need a person's approval of the exact command. - A model may only tighten. If a model is consulted at all, it can turn an Allow into an Ask. Nothing ever becomes an Allow because a model said so. - Pinned policy. Policies are YAML with tightening overlays, canonicalised to JSON and identified by their SHA-256. Each launch is pinned to one policy hash. An invalid document fails closed; there is never a fallback policy. - Panics are denials. A classifier panic is caught and becomes Deny. - The daemon being down is a denial. If the hook cannot reach the daemon, every tool call is refused, reads included. Approvals are never auto-answered. The code states the gate's limits in its own documentation, and so do we: the gate is defence in depth against mistakes and runaway agents, not a security boundary. The controls that hold against a hostile agent are server-side (scoped credentials, branch protection) and the OS sandbox. The gate exists so that the common failure, an honest agent doing the wrong thing at the wrong time, is stopped deterministically and recorded. ## 6. Leases and fences ![Two seat lanes cross a timeline fence marked 7 to 8; Seat A's token 7 write bounces back, while Seat B's token 8 write passes through.](https://f200.ai/media/editorial/03e068067a6ce4d553787e6fe437d3c74a4acdc4669be392305569d3c2a0d239.webp)Fence tokens reject stale writes and admit the current lease holder. Anything two seats could fight over is a leased resource: a work item, a slot in a heavy-job pool, a branch, a step in a flow, the merge train of a repository, the single writer of an issue-tracker project, or a claimed path in a repository. A lease alone is unsafe. A holder can stall past its expiry, wake up and write anyway. So every resource also carries a fence: a number that only grows. Each grant and each revoke moves it on, and every guarded write checks the writer's fence inside the same transaction as the write. ![Seat A receives fence 7 and stalls; its lease expires, Seat B receives fence 8, and the store refuses A’s stale write while accepting B’s current write. External writers use HMAC tokens and retain each resource’s highest fence.](https://f200.ai/media/editorial/e572a344ebe02a1396c8cc8f826effe59e6034b3e73fea2347a230b3c3d44b23.webp)A newer fence prevents an expired holder from writing stale work. The rules are one pure function, decide(view, command, now), over six commands: grant, renew, release, validate, expire and revoke. The store applies the resulting changes inside the caller's write transaction. A few constants keep it honest: no lease lives longer than 24 hours, a holder may have at most 8 live leases, and a grant is refused if the clock reads more than 5 seconds earlier than the newest grant, so a clock that jumps backwards can neither mint grants nor shorten a lease. Holders are typed (seat, job, flow, host), and cleanup for one type never touches another type's leases. That rule exists because the earlier platform once let a seat's leak guard free a background job's lease. For writers outside the database transaction, the daemon issues a signed, expiring fence token keyed by a host secret that never appears in an agent's environment or logs. The receiver checks the signature in constant time first, then refuses any fence lower than the highest it has accepted for that resource. Every lease implementation, the local engine today and any future broker, must pass the same shared conformance fixtures: stale renew and release, revoking a stale write, idempotent regrant, double expiry sweeps, conflicting grants and validation after expiry. ## 7. The work queue Work items move through an explicit state matrix. There are four live states and five terminal ones, and terminal states refuse every command. | From | Command | To | | --- | --- | --- | | Pending | Claim | Claimed | | Pending | Block / Handoff / Deny / Cancel | as named | | Claimed | Start | Running | | Claimed | Complete / Fail | Done / Failed | | Claimed | Block / Handoff / Deny / Cancel | as named | | Running | Complete / Fail | Done / Failed | | Running | Block / Handoff / Cancel | as named | | Blocked | Unblock | Pending, or Claimed if the prior claimant can take it back | | Blocked | Claim / Block / Handoff / Deny / Cancel | as named | An exhaustive test walks every state against every command. Claims are leases with fences, so a seat transitions its own item by presenting its fence. When an item closes, items blocked directly on it are released in the same transaction. Waiting without polling. Agents are bad at waiting. Shiftyard bans polling outright: a seat that needs CI to finish blocks its item on a canonical external reference (a commit's checks, a pull request, a CI run) with a wake-after between 5 minutes and 24 hours, and ends its turn. The daemon wakes it when the reference changes, with a slow fallback wake if nothing arrives. A wake is not a result: the seat re-reads the evidence when it wakes. Idle dispatch. An idle seat is offered its next pending item addressed to it, most urgent first and then oldest, once per idle window. The seat claims it itself. Finishing work comes before starting work. Work-in-progress limits. New build claims wait while a repository already has 15 open pull requests from the factory. ## 8. Verification and the land train ![Pull request cards on train wheels follow a magenta track through verify, review, approve, and merge signals to a main station, with queued cars stopped at the red verify signal.](https://f200.ai/media/editorial/b608d6e7a866fbe2a30c3e847099c516849495c56c9f1ecb3c6aed1cb6df12bc.webp)The land train carries pull requests through checks toward main. Two mechanisms stand between an agent saying "done" and a change reaching main. Stop-hook verification. A seat may finish its turn only once the repository's declared checks pass. The check declaration is read from the daemon's own mirror at a base commit the daemon resolved, never from the seat's working copy. The checks run in a fresh checkout built from the work's tree, with protected paths (tests, fixtures, CI configuration) taken from the base, and with a cleared environment. So an agent cannot make its turn pass by editing the tests or the check declaration. A pass lets the turn end; a failure blocks it and hands back the redacted output tail; after repeated refusals a person decides. Verdicts currently record isolation = weak, because the separate verify user does not exist yet. The land train. ![A two-row pipeline follows a queue item through a fenced claim, seat edits, stop-hook verification, PR creation, risk-tier reviews, SHA-bound checks, landability, person-approved LAND NOW, a pinned-head merge driver, and main; failed verification blocks the turn and a failed release verdict freezes the train.](https://f200.ai/media/editorial/638814d923e990ca406eb735fbb3ec434996a06833b843bfcefe58c4ce15d342.webp)Every merge passes verification, reviews, current-head checks, and a person-approved land batch. Details that came from real incidents: - Verdicts are bound to the exact head commit. A verdict on an older head does not count. - Rebases. A verdict is carried across a rebase only when the base, the patch-id and the set of changed files are all the same. Otherwise it is superseded and the PR gets one re-review per kind. CI results never carry. - Risk tiers. Tiers come from path rules. An unclassified PR is normal; unknown files are read as infrastructure. An infrastructure batch is always size one. - Only the head the verify gate admitted can land. The merge driver only touches pull requests the engine opened, pins the head SHA on the merge and never uses an admin bypass. It runs every ten minutes and shortly after any verdict, approval or green check. ## 9. Scheduling, capacity, routing and budgets Liveness from evidence. The wake core never stores "alive" as a flag. Liveness is computed from evidence: the holder, the process, the screen, the hooks. Every launch is a resume; there is no fresh launch except through the recycler. A permanent-failure breaker stops a seat that keeps failing to launch. Housekeeping that is on by default. | Behaviour | What it does | | --- | --- | | limit holds | a seat that hits a usage limit has its wakes held until the reset; two agreeing seats open an account-wide limit episode | | stuck alarms | a busy seat with no progress raises an item to its coordinator | | orphan adoption | after a daemon restart, adopt a live agent whose holder survived, after proving identity (fenced token, kernel peer uid, holder executable, pid and start time, plan hash) | | reaper | sleep idle seats (10 minutes for unit seats, 30 for core seats) after saving their work-in-progress to a ref and snapshotting the screen | | recycler | start a fresh session for an implementer at 60% context or after a finished item, seeded with a recovery packet; others are compacted | | idle dispatch | offer an idle seat its next item | Capacity. The working seat target is floor(min(ram_seat_cap, cpu_seat_budget) × thermal_factor). The daemon samples the host every 15 seconds, keeps a 2 GiB memory reserve plus 1 GiB per new seat and a disk reserve, and gates queued resumes on CPU below 85%. Heavy jobs (builds, test suites) take a slot from a leased pool through a governor command that runs the job in its own process group, renews the slot at a third of its remaining time and releases it when the job ends. A heat guard that renices builds, caps concurrent build trees and backs off on thermal pressure is designed and in review. Routing tiers and floors. Models are grouped into three tiers. A crew may lower a tier; only the policy may raise one. Each stage of work has a floor: | Stage | Minimum tier | Effort | | --- | --- | --- | | implement / fix (small, medium) | 2 | medium | | implement / fix (large or unknown) | 3 | medium | | QA and code review | 2 | medium | | security review | 3 | high | | security delta review | 2 | high | | coordination | 3 | medium | | design | 3 | high | Tier 3 never runs at low effort. Budgets and usage. Budget admission is pure fixed-point arithmetic. Token use and list price are read from each CLI's own local records into a usage ledger, and metrics can arrive over a loopback OpenTelemetry receiver. The balancer. A pure engine decides where seats should run across accounts: hard filters that fail closed, then ranking by headroom before the next reset, the cheapest suitable role chain and slack; failover at a cold boundary and fail-back after reset; and caps learned for windows a vendor does not publish. Today the balancer records its moves; applying them is in review. Model gateway. For components that call models directly, the daemon serves a loopback gateway that speaks the OpenAI Responses, OpenAI chat-completions and Anthropic messages protocols, walks a fallback chain with per-entry cooldowns, classifies errors, meters usage into the ledger and redacts on the way out. ## 10. Isolation and egress Sandbox. On macOS every seat runs under a per-seat, deny-by-default Seatbelt profile (derived from the Apache-2.0 Codex sandbox profiles). It hides other seats' state, allows only the seat's own terminal, restricts loopback by address family and denies terminal input injection. Applying the profile fails closed, and an escape test suite runs against it. Two limits are documented rather than hidden: Seatbelt does not stop one process from reading another's arguments through the kernel, and there is no Linux sandbox yet. Agent OS identity. A small root-installed helper can run agents under their own OS user, with unsafe code confined to one module. The running daemon still launches seats as the same user today. Workspaces. Each seat has its own clone of each repository, borrowing objects from a daemon-owned bare mirror. Work in progress is saved to a per-seat ref, retired clones are parked and pruned after 30 days, and build directories are warmed with copy-on-write. Egress. There is exactly one way text leaves a host. A redacted-text type can only be constructed by the sanitizer, and every transport accepts nothing else. Deny terms are matched in a folded form, the egress log keeps only hashes and counts, never content, and a missing or empty deny list means nothing leaves at all. An operator can preview exactly what would leave before it does. ## 11. Storage and audit - One writer thread plus a pool of read-only connections. - Two databases. The engine database, and an attached, append-only, hash-chained audit database. An audit command recomputes the chain end to end. - Migrations are forward-only and checksummed, with a backup before every run. - The outbox. Side effects (GitHub calls, issue updates, notifications) are written as outbox rows in the same transaction as the state change and executed by an effect runner, so a crash cannot produce a merged PR without a record or a record without its effect. - Redaction before storage. Credential shapes are replaced before any text is stored. - Secrets. Daemon-held secrets are sealed with XChaCha20-Poly1305 bound to the secret's name, with the data key in the OS keyring. The secret type cannot be formatted and is wiped on drop. - Authority records can only be written through a sealed key type, and a dependency policy check bans every other crate from depending on it. ## 12. Memory: index, embeddings and governance ![Dashed source icons for git, PRs, issues, and sessions connect to solid chunker and embed components, vector dots, a chained ledger book, and a dashed search magnifier.](https://f200.ai/media/editorial/c78f4ed9d23fbe979a09858be6c4bf31e20070098f03180706cd2376dd2630c1.webp)The memory pipeline connects chunking, embeddings, and a hash-chained ledger with planned sources and search. Agents forget. Our team has been running a separate memory service for months: it indexes our repositories, git history, every agent session and a ledger of remembered decisions, and serves all of it over MCP. At its last backup it held 179,037 indexed chunks. It is written in Go and uses a local embedding model through a separate model server. On 6 October we decided that memory should not be a separate product. It becomes native code inside the Shiftyard daemon. The building blocks are in the repository; composing them into the daemon and cutting over is the work of the coming days. This section separates the two. ![Solid built memory blocks include chunking, embedding, the index store, and a governed append-only ledger; dashed planned blocks include sources, hybrid search, and MCP tools. A model-selection gate lists throughput, cosine, ranking, and licence criteria.](https://f200.ai/media/editorial/ef1245392f374b5374148c7ad274ba15e6d4ceb5da026044b78f1f33ea9ca7ab.webp)Memory processing and governance are built while ingestion and retrieval remain planned. Chunking. We ported the per-language regex rules of the existing service rather than switching to tree-sitter. Pure Rust, the same languages and output that can be diffed against the reference. Code is split at top-level definitions together with their leading comments and attributes; prose is split at headings outside code fences; small spans are merged and large ones split on line or paragraph boundaries; cuts move back to a UTF-8 boundary; every piece of an oversized code span is capped at 4,000 bytes. A parity test checks spans, symbols and imports against the reference implementation's output; on a 32-file test corpus the outputs match except for two documented deviations. A tree-sitter chunker is a later decision, gated on beating the regex baseline on code-scope retrieval. Embeddings. The model layer defines Embedder, Reranker and Classifier interfaces and one shared post-processing pipeline: an 800-character input cap, the model card's query and document prefixes, Matryoshka truncation, L2 normalisation and an int8 form with sign bits. A model id names a vector space (name, precision, dimensions and a hash prefix), and vectors from different ids are never mixed. Models are open-weight GGUF files only, run in process through llama.cpp: Metal on macOS, CPU elsewhere, GPU by default with an automatic CPU fallback whose reason is recorded. One thread owns a loaded model. User text is tokenised with special-token parsing switched off, so a document cannot inject control tokens. We chose not to use ONNX Runtime. Model supply chain. A model manifest pins a 40-character commit and a SHA-256, accepts only Apache-2.0 or MIT licences with no override, and accepts GGUF only, never pickle. Provisioning asks for consent with the size and licence shown, downloads with a size cap and resume, verifies the file before every load, works offline once cached and uses file locks for fetch and use. One candidate embedding model was dropped from consideration purely on its licence terms. Governed memory. Remembered facts and decisions live in an append-only, hash-chained lifecycle ledger: approve, hold, supersede, retract, quarantine and restore, each atomic with its ledger event. Imports are idempotent and keep provenance. A write to a shared scope stays pending until an owner approves it. Cutover plan. Backup (done 6 October), a four-model quality and speed evaluation, a parity proof, composition into the daemon, a 48-hour shadow run, then the switch, one seat first and then all, and finally the old service read-only and retired. The target window is 8 to 15 October. The rule written into the plan: if no model meets both the quality and the speed bar, we report the measured results; we never lower either bar. ## 13. Models and training Shiftyard trains no model weights. That is an explicit non-goal, not an omission. Training models, or using another model's outputs as labels, is out of scope for the memory work. Hosted judgment results are never used as training data. What we do instead is select open models against fixed gates, and optimise text (guidance and skills) against held-out evaluations. Selecting the embedding model. The candidates are open-weight embedders in the 0.1 to 0.6 B parameter range: Qwen3-Embedding-0.6B, nomic-embed-text-v1.5, the BGE family (bge-m3, bge-small-en-v1.5) and IBM Granite embeddings. A candidate passes only if all of these hold: | Gate | Bar | | --- | --- | | throughput | median warm chunks/s at 800 characters above the current baseline, and above 15 | | numerical agreement | mean cosine against the same model under the reference runtime ≥ 0.99, minimum ≥ 0.97 | | retrieval quality | file-level MRR@10 ≥ baseline − 0.01 | | licence | Apache-2.0 or MIT | Cutover itself has a stricter, statistical gate: a paired bootstrap with 10,000 resamples on at least 150 queries, whose 95% confidence interval lower bound must be ≥ −0.02 on both MRR@10 and weighted recall@10, with search p95 at or under 293 ms and a daemon footprint at or under 78 MB excluding the model, at 15 seats. Quantisation has its own gate (cosine ≥ 0.99, ΔMRR ≤ 0.01, classifier ΔF1 ≤ 1 point). A reranker is optional and must earn its place on nDCG@10. What we have measured so far. | Measurement | Result | Status | | --- | --- | --- | | reference service, M2, 3,000-char inputs | 6.1 chunks/s | measured | | reference service, M2, 1,500-char inputs | 14.3 chunks/s | measured | | reference service, M2, 800-char inputs | 15–28 chunks/s | measured | | reference service, pooled file-level MRR@10 at 800 chars | 0.529 | measured | | native, Qwen3-Embedding-0.6B Q8_0 (1024-d), batch 32, M2 + Metal | 11.3 chunks/s | preliminary: laptop under load, not a clean run | | reranking in the reference service | hit@1 −0.085 | measured: it hurt, so it is off by default | The native number is below the baseline range, and we are publishing it anyway: it was taken on a loaded laptop and is not a gate result. Performance claims in the codebase must be measured in a fresh process, on fixed inputs, after a warm-up, as the median of several runs. The negative reranking result is the reason the reranker is opt-in and gated. Experimental: automatic guidance and skill learning. On an unmerged branch we are testing a loop that improves the text agents run on (their guidance files and skills) without training anything: - A local Qwen2.5-1.5B-Instruct model (Q4_K_M GGUF, about 1.1 GB) runs in a daemon-managed llama.cpp child process. API spend is zero, each run has a 10-minute budget and makes at most three changes. - Runs happen daily (guidance in the morning, skills an hour later) and after outcome events. - A candidate must strictly improve on the training set, then pass one sealed, paired, held-out evaluation, then a person reviews it before it is activated. - Retrieval inside the loop uses BGE-small-en-v1.5 (Q8, 384-d) for a shortlist of 8, a Jina turbo reranker, and BM25 plus dense retrieval fused with reciprocal rank fusion (k = 60). The measurements so far are deliberately small and do not establish production quality. On 10 English and 10 Ukrainian queries, top-1 retrieval was 80% and 90% with query translation, 20% for Ukrainian without translation, and 70% for English before fusion. On 20 fresh English queries it moved from 65% to 70%. In screening, four smaller models (Qwen2.5-0.5B, Qwen3-0.6B, Qwen3.5-0.8B and SmolLM2-360M) each failed at least one of five guidance checks. No change has yet earned promotion. Advisory judgments. Four typed judgments help the operator: queue priority, duplicate ticket, a seat stuck in a loop, and pull-request scope drift. Each has a firm probability band (for example p ≥ 0.9 for a duplicate). They are advisory only. A judgment may add a note, a badge or a display order; it may never grant, block, merge or reorder a queue, and "no answer" must behave exactly like "off". The backend is hosted or off today, and a local decider that shadows the hosted one is planned. ## 14. Testing and measurements The codebase on main at the time of writing: | Metric | Value | | --- | --- | | Rust workspace | 49 crates, about 397,000 lines (261,000 source, 136,000 tests) | | Web UI | about 65,000 lines of TypeScript (React, Vite, Playwright) | | Test functions | 4,613 (static count) | | Gate classification corpus | 483 cases | | Gate bypass corpus | 987 cases (must-gate bypasses plus read-only negative controls) | | Conformance fixtures | 14 (leases, fleet reads, handshake, claims) | | Known-failure baseline | empty | How we test. - Property tests on the gate, the lease rules and secret sealing. - Fuzzing of the gate classifier, the usage parsers, and the agent-identity helper's arguments (a million iterations by default). A fuzz crash becomes a regression test before it is fixed. - New review findings become failing corpus cases first. - Exhaustive matrices, such as every work state against every command. - No wall clock in tests. Tests use a fake clock, and a guard test enforces it. Test retries are set to zero in every profile. - Conformance as a contract. Fixtures are protobuf JSON; a run that skips a required fixture fails. - CI runs on self-hosted Linux arm64 runners only, the main suite runs in about a minute, and a hung test is killed at 300 seconds. macOS coverage runs on maintainers' machines. A public-text guard runs on every pull request. Choosing the terminal model, measured. Before writing the screen reader we replayed five real recorded Claude Code sessions plus synthetic Codex and stress recordings through three Rust terminal emulators, comparing each against a headless reference emulator. Two identical runs on an M-series Mac: | Terminal crate | Text mismatches | Unexplained modes | Failed checkpoints | Throughput (MB/s CPU) | Memory per 200×50 screen + 10k scrollback | Result | | --- | --- | --- | --- | --- | --- | --- | | alacritty_terminal 0.26 | 0 | 0 | 0 | 162.8 | 49,922 KiB | chosen | | avt 0.18 | 0 | 20 | 4 | 81.9 | 32,194 KiB | rejected: no bracketed paste | | vt100 0.16.2 | 144 | 0 | 0 | 85.4 | 63,328 KiB | rejected: unmaintained | The same spike showed that 30 seats with 10,000 lines of scrollback each would cost about 1.5 GB, which is why the default scrollback is 2,000 lines. What we have not measured yet. Gate decision latency, daemon RPC latency (the histograms exist; we have not published numbers), throughput or merged pull requests per day attributable to the factory, and cost per merged pull request. The last one is the outcome metric we care most about, and the usage ledger exists to feed it. ## 15. Running our own work on it On 5 October 2026 we moved our own engineering team off the earlier platform and onto Shiftyard in one hard switch, with no parallel run. The import moved the open work across and checked that no authority records (grants, approvals) travelled with it. The go/no-go list had six blockers (per-seat accounts, MCP for seats, guardrail parity, Codex wake registration, disk and session resume), and some were repaired in flight. Since then Shiftyard has largely been built by agent seats running on Shiftyard: the repository has 366 merged pull requests, and the busiest day after the switch had 356 commits. The same mechanisms described above (the gate, the land train, verdicts bound to head commits) govern the agents that are writing the code. ## 16. Roadmap and YardBridge ![A magenta voyage route joins filled buoys dated Sep 25, Oct 5, and Oct 6, hollow buoys dated Oct 12 and Oct 15, and a dashed continuation to an island labelled YardBridge.](https://f200.ai/media/editorial/8b37ecf545e51d36da2c8d65f873a4376dd06bf0ab927c9ddad3c41d1201de2a.webp)Completed and planned milestones chart the voyage toward YardBridge. ![A 2026 milestone timeline marks completed work from September 25 through October 6, planned October memory migration and retirement, next items in review, and later multi-host, Linux sandbox, and public release work, with a separate indicative YardBridge lane.](https://f200.ai/media/editorial/775d737fafeff8bc32ca61d018bb24303867b6797b467bd3d1184ad85a911347.webp)The roadmap separates delivered foundations, reviewed next steps, and planned horizons. Multi-host. A host-to-host link protocol, a fleet read service and conformance fixtures exist; the coordinator that implements them does not. One host acting as the coordinator for a person's other hosts is planned. YardBridge is the planned organisation layer on top of Shiftyard. The design installs it in the customer's own AWS account, with yards always dialling out and the control plane never connecting into a yard. The first release is scoped to enrolment, fleet visibility, customer-signed policy (Ed25519 signatures over canonical documents, a host-pinned trust root, effective permissions as the intersection of org and host policy, with the built-in floor always preserved) and exact outcome evidence. Shared claims across hosts, strict fleet budgets, a visual flow builder and organisation-wide memory come later. The indicative path to a first partner pilot is 10 to 12 weeks; it is a plan, not a delivery date, and none of YardBridge is available today. ## 17. What we do not claim yet Engineering posts about agents tend to round up. Here is the list of things Shiftyard does not do today: - It is not installable, and the public repository is not open yet. - Memory, the code index, embeddings and reranking are not running inside the daemon; the building blocks exist and the cutover is planned. - No embedding model has been selected, and we have no retrieval-quality number for Shiftyard's own memory yet. - Shiftyard trains no models. - OpenCode seats, the heat guard and applying the balancer's moves are in review, not running. - There is no Linux sandbox and no multi-host coordination. - The gate is not a security boundary, and the verify step's isolation is recorded as weak. - We have measured no productivity, cost or quality improvement, and we are not implying one. ## Get involved Shiftyard is licensed Apache-2.0, and the names f200, Shiftyard and YardBridge are trademarks of f200: forks are welcome under a different name. The public repository is coming soon, with a Developer Certificate of Origin sign-off for contributions. If you run coding agents in parallel and recognise the failures in section 1, or you want to be an early YardBridge design partner, book a 30-minute call with the founders. # Software factories: why every company, from enterprise to solo founder, needs one Published: 2026-10-07T19:59:45.685Z Source: https://f200.ai/blog/software-factories-why-every-company-needs-one ![An overhead shipyard with four crane-equipped slipways feeding identical vessels along a magenta route through an inspection gate into open water.](https://f200.ai/media/editorial/64f9fa8ae54093da9ec2890c6ea5061e44bba2b879e232587e5c4c72d28875e1.webp)A software factory builds agent work in parallel and sends it through inspection before release. Every founder we talk to asks a version of the same question. "My engineers already use AI. Why isn't the company shipping twice as fast?" The short answer: an AI coding assistant makes a person faster at writing code. A software factory makes a company faster at shipping working software. Those are different things. The research from the last two years explains the difference, and it makes the business case for building the second one. This post is for CEOs, CTOs, product founders and solo builders. It covers what a software factory is, what the data says about the value, where the value leaks away, and how to start at your stage. Every number is sourced at the end. Where the evidence cuts against the story, we show that too. The one-paragraph version. AI agents can now do multi-hour engineering tasks, and that capability is doubling roughly every four months. Adoption is close to universal. But the gains show up in company results only when the work around the code is redesigned: queues, verification, review, merge, budgets and memory. Without that, AI produces more code, more review load and more defects, and the business barely moves. A software factory is the system that turns agent capability into shipped, trustworthy product. ## 1. What a software factory is A software factory is a governed production line for software, where AI coding agents do much of the building and people decide what gets built and what ships. ![Eight steps connect goals and ideas to production, with policy gates, verification and risk-based review. Shared memory supports every step; measured outcomes feed back to goals.](https://f200.ai/media/editorial/ba340ec5eb52091dd43b8d99b29ba6ed60fa544acfe86d20e7d5c58cc67b1140.webp)What a software factory is It has six parts, and each one exists because agents fail in a specific way without it: | Part | What it does | The failure it prevents | | --- | --- | --- | | Intake and queue | Turns goals into small, well-defined work items with owners and priority | Agents working on the wrong thing, or two agents on the same thing | | Agents | Claude Code, Codex and similar tools doing the implementation, each in its own sandboxed workspace | One agent's mess spilling into another's work | | Policy gates and budgets | Deterministic rules on what an agent may run and spend | Force-pushes, deleted databases, surprise cloud bills | | Verification | Tests and checks that must pass before an agent may say "done" | "The tests pass" when they never ran | | Review and merge | Risk-based human review and an exact, auditable merge pipeline | Unreviewed code reaching production | | Memory | What was decided, tried and learned, searchable by every agent | Every session re-deriving yesterday's work | The key idea: the agent is not the product. The system around the agent is. ![Comparison of human-only, copilot and software factory operating models across code authorship, work units, bottlenecks, governance, scaling and measured gains.](https://f200.ai/media/editorial/057d14f1637075a80a37f7c17ad78a7f1db34fbf88a63e21e8e3e079e78d6edf.webp)Three ways to build software with AI ## 2. The capability curve: why this is a now problem In 2023 the best AI model could reliably finish a software task that takes a human expert about 4 minutes. By February 2026, the best models could finish tasks that take an expert about 12 hours, half the time. That is a ~180× increase in three years. ![Linear-scale task horizons by model release date: GPT-2 0.05 min; GPT-3.5-instruct 0.6 min; GPT-4 4.0 min; GPT-4o 7.0 min; Claude 3.5 Sonnet 20.5 min; o1 38.8 min; Claude 3.7 Sonnet 60.4 min; o3 119.7 min; GPT-5 203 min; Gemini 3 Pro 224.3 min; Claude Opus 4.5 293 min; GPT-5.2 352.2 min; Claude Opus 4.6 718.8 min. Illustrative least-squares exponential fit to the shown 2023–2026 observations on a linear hours axis; observations remain unchanged.](https://f200.ai/media/editorial/963ff14727317e810ce71e5e82fdb6d39b456456ad33e3ea7706413c259b8331.webp)The 50% success horizon rose from GPT-4’s 4 minutes to Claude Opus 4.6’s 718.8 minutes (~12 hours). Linear hours reveal the exponential shape; the curve is an illustrative least-squares exponential fit to the displayed 2023–2026 observations, not a forecast. METR reports ~129-day doubling for its broader trend..") METR, an independent research organisation, measures this "time horizon": the length of task, in expert-human time, that an AI agent completes with 50% success. Since 2023 it has doubled about every 129 days. Over the full history since 2019, the doubling time is about 188 days. What this means for a business: - A 4-minute task is autocomplete. A person stays in the loop for every line. - A 1-hour task is a delegated ticket. Someone reviews the result. - A 12-hour task is a day of engineering. You need a queue, a budget, checkpoints and a way to verify the outcome without redoing it. The tools crossed from the first category to the third in about 30 months. Most companies' processes did not. A note on benchmarks: public coding benchmarks like SWE-bench Verified went from about 50% to over 90% in under two years, and OpenAI stopped reporting the benchmark in February 2026 after an audit found many of its tasks flawed. Treat any single leaderboard number with caution. The direction is not in doubt; the exact score is. ## 3. Adoption is near-universal. Trust is not. ![Use or plan to use AI: 76% in 2024 to 84% in 2025; distrust of AI accuracy: 31% to 46%; AI agent use: 31% in 2025 to 59% in the April 2026 pulse.](https://f200.ai/media/editorial/75f9887f2232bf3b2dcb8576fc8720492acc75e2d29c54fb19376d1718fab396.webp)AI adoption and distrust both increased, while reported agent use rose to 59% in the April 2026 pulse. - 90% of software professionals now use AI at work, a median of two hours a day (Google DORA 2025, about 5,000 respondents). - 84% of developers use or plan to use AI tools, up from 76% the year before (Stack Overflow 2025, 49,000+ responses). - Use of AI agents, not just chat or autocomplete, rose from 31% in 2025 to 59% in April 2026 (Stack Overflow pulse survey). - Google says 75% of its new code is now AI-generated and approved by engineers, up from about 25% in late 2024. ![Google 75% (Apr 2026); Robinhood ~50% (Jul 2025); Coinbase ~40% (2025); Microsoft 20–30% (Apr 2025); Uber ~10% by autonomous agents (May 2026). Google trend: 25% Oct 2024, 50% fall 2025, 75% Apr 2026. Executive statements; definitions differ.](https://f200.ai/media/editorial/70b22af31bbe0acd46b47deec61ab880d222b1c6c0ee8a910a6e45214f9a3005.webp)Reported AI-generated code shares range from ~10% by autonomous agents at Uber to 75% at Google; definitions differ. The open-source world shows the same shift. GitHub's 2025 Octoverse counts 180 million developers, 1.1 million public repositories using an LLM SDK (up 178% in a year) and 518.7 million merged pull requests (up 29%). The most-starred open-source coding agents were almost all created in 2025: four of them passed 100,000 stars each within about eighteen months. ![GitHub stars by repo creation date: opencode: 212,182, Apr 2025; Claude Code: 149,734, Feb 2025; OpenAI Codex CLI: 128,169, Apr 2025; Gemini CLI: 107,245, Apr 2025; OpenHands: 90,185, Mar 2024; MetaGPT: 70,766, Jun 2023; Cline: 69,981, Jul 2024; Goose: 55,037, Aug 2024; Aider: 49,409, May 2023; Continue: 36,148, May 2023; ChatDev: 34,458, Aug 2023; Kilo Code: 27,520, Mar 2025; Roo Code: 24,284, Oct 2024; SWE-agent: 20,497, Apr 2024. Four projects created in 2025 have 597K+ stars combined.](https://f200.ai/media/editorial/acf72ae876afa1446a3e2168911a51162b98cb639486c630d048d529242384d9.webp)Four coding-agent projects created in 2025 passed 100,000 GitHub stars each, reaching 597K+ combined. At the same time, trust is falling: - Only 24% of DORA respondents trust AI output "a lot" or "a great deal". - 46% of Stack Overflow respondents distrust the accuracy of AI tools, up from 31%. - 66% say the biggest frustration is code that is "almost right, but not quite". ![Trust in AI output: 24% a lot / a great deal, 46% somewhat, 30% a little / not at all. 90% use AI; median usage is 2 hours per day.](https://f200.ai/media/editorial/c34024646bb4c552501304f225b08f030d59f0085fd231fe9e1490457b08b50a.webp)Only 24% of DORA respondents expressed high trust in AI output, despite 90% using AI. This gap, near-universal use with low trust, is the whole business problem in one picture. People are generating more code than ever and believe less of it. Somebody has to check it, and that somebody is your most expensive engineers. ## 4. What the evidence says about productivity Here are the controlled studies and large field measurements, side by side. ![Effects: Copilot +55.8% faster; Google +21% faster (~96 vs 114 min); Microsoft/Accenture +26.1% tasks ±10.3; Microsoft CLI +24.0% merged PRs, CI +14.5 to +33.7, daily users +50.1%; Faros +21% tasks; METR −19% slower. METR 2026 follow-up faster on average but inconclusive due to selection bias. METR experts predicted +24%, measured −19%, believed +20% afterwards.](https://f200.ai/media/editorial/42ad7149cb6e8f1531c3c1eff61cd628fcf7ebe9a5883fbb0c71b094d77027a4.webp)Reported effects vary across settings, with METR’s 2025 study finding a 19% slowdown among experienced developers. | Study | Setting | Result | | --- | --- | --- | | GitHub Copilot RCT (2023) | One scoped task: build an HTTP server | 55.8% faster | | Google internal RCT (2024) | 96 Google engineers, enterprise task | ~21% less time | | Microsoft, Accenture, Fortune-100 field experiments (2025) | 4,867 developers, real work | +26% completed tasks; juniors gained most | | Microsoft agentic CLI rollout (2026) | Command-line coding agents, 4 months | +24% merged PRs, no decay; daily users +50% | | Faros telemetry (2025) | 10,000+ developers, 1,255 teams | +21% tasks, +98% PRs, but flat company-level metrics | | METR RCT (2025) | 16 expert open-source maintainers on their own repos | 19% slower, while believing they were 20% faster | | METR follow-up (2026) | 57 developers, 800+ tasks | Faster on average, but too biased by selection to be conclusive | Three things stand out for a business owner. First, the gains are real and they repeat. Well-defined work, measured inside a real organisation, consistently shows 20–30% more output, and agentic tools in 2026 show similar or better, sustained over months. Second, people misjudge their own speed. In METR's 2025 study, experienced developers predicted AI would make them 24% faster, were actually 19% slower, and still believed afterwards they had been 20% faster. Self-reported productivity is not a metric. If you don't measure, you don't know. Third, individual output and company output are different numbers. Faros saw teams merge almost twice as many pull requests, and saw no improvement at the company level. McKinsey's 2026 Technology Trends Outlook reports the same pattern across companies: AI tools raised coding activity by 180%, but shipped releases rose by only 30%; only a quarter of companies achieved meaningful acceleration, and nearly 30% saw productivity fall after adopting agentic tools. The next section explains why. ## 5. What it looks like when it works The companies getting real results did not just hand out licences. They built pipelines. ![Airbnb: 1.5 years estimated to 6 weeks, 97% automated, ~3.5K files. Amazon: ~50 developer-days per app to hours, 30,000 apps, ~4,500 developer-years and ~$260M/yr saved. Google: 6× faster migrations. Stripe: 1,300+ fully agent-written PRs merged weekly, all human-reviewed. Uber: background agent opens 11% of PRs; AI review covers 90%+ of ~65K weekly diffs.](https://f200.ai/media/editorial/bd8cd19732330288d63dc3d52b34c934b0ccbfeefa0c0af57268c3809a51c572.webp)Company reports describe faster migrations and substantial agent output, alongside review practices. - Stripe merges more than 1,300 pull requests a week written end-to-end by its internal agents, every one reviewed by a person. Work starts as a request in Slack and ends as a PR that has already passed CI, built on isolated environments and hundreds of internal tools. - Airbnb migrated about 3,500 test files to a new framework in 6 weeks, against an original estimate of 1.5 years, with 97% of the work automated. - Amazon used its coding agent to upgrade 30,000 applications to a new Java version, cutting each upgrade from about 50 developer-days to hours, and estimates 4,500 developer-years and $260 million a year saved. - Google reports a large code migration done by agents and engineers together six times faster than a comparable one done by people alone. - Uber's background agent opens 11% of all its pull requests, and its AI reviewer covers more than 90% of about 65,000 changes a week. The flip side is at Uber too: the company spent its entire 2026 AI-coding budget in about four months, and its COO said publicly that the link between agent usage and shipped features "is not there yet". Same tools, same company: where there is a pipeline, there are results; where there is only usage, there is a bill. ## 6. Where the value leaks: the review bottleneck When agents write more code, every downstream step gets more work: review, testing, merging, deploying, fixing. ![High-AI teams vs baseline: tasks completed +21%, PRs merged +98%, PR size +154%, review time +91%, bugs per developer +9%. Company-level delivery metrics: flat.](https://f200.ai/media/editorial/3c6ebf1a3bc6c660663a8669bf9abcad2f25e427d1d578bef9afa61349ffccbc.webp)High-AI teams produced larger PRs and spent more time on review while company-level delivery metrics stayed flat. In Faros's data, high-AI teams merged 98% more PRs, but their PRs were 154% larger, review time went up 91%, and bugs per developer rose 9%. The constraint moved from writing code to verifying it, and verification capacity didn't grow. It gets worse over time. A 2026 study of 400 reviewers and 11,429 reviews found that reviewers approve agent-written PRs more and more easily: approval rose from 27.9% to 42.4% across reviewers' own history, while their inline comments fell 22%. Over the same period they became stricter with human PRs. ![Agent PR approval rates by reviewer experience decile 1–10: 27.9%, 27.1%, 30.0%, 28.1%, 33.3%, 35.6%, 32.6%, 34.2%, 38.6%, 42.4%. Approvals +14.5 points; inline comments −22%.](https://f200.ai/media/editorial/9ffeee26d36d2d933ec94c2513e6c8239807db4c4b31d4c180fc7be9e4ed424e.webp)Approval rates rose from 27.9% to 42.4% across reviewer experience deciles as inline commenting declined. ![Dozens of small boats converge across a wide bay toward a narrow harbour mouth guarded by one inspection tower, with only a few boats beyond it.](https://f200.ai/media/editorial/230f4fd460e509a98dcd00cd854949ad58c86c3d00dbb304216bc15c64c348a6.webp)Output grew; verification capacity did not. On public GitHub, the review gap is measurable. Coding agents opened millions of pull requests in the past year (Codex about 5.1 million, Claude Code about 4.2 million, Copilot about 1.9 million). Most of them merge, but for two of the three biggest agents fewer than a third of merged PRs got a human review. And merging isn't the end of the job: merged agent PRs need follow-up fixes at 1.62× the odds of human PRs, and a Stanford study of 6,000 real agent sessions found that only 44% of agent-written code survives into commits. ![PRs opened: Codex 5.1M; Claude Code 4.2M; Copilot 1.9M; Jules 1.2M; Cursor 614K; Devin 161K. Merge rate / human review among merged PRs: Claude Code 91.5% / 30.5%; Codex 87.5% / 28.6%; Copilot 68.1% / 80.5%. Merged agent PRs need follow-up fixes at 1.62× the odds of human PRs.](https://f200.ai/media/editorial/16ea10b270a85b5f988cc7997bb7f58daa3109f25afab8234f7638c02195aa0d.webp)Most merged agent PRs were never reviewed by a person; merged agent PRs had 1.62× the odds of follow-up fixes. Developers feel both sides of this. Atlassian's 2025 developer experience survey found 68% of developers save more than 10 hours a week with AI, while 50% lose more than 10 hours a week to organisational friction. The time AI gives back is easily eaten by the system around it. And the quality signals are mixed: - Veracode found security flaws in 45% of AI-generated code tasks (over 70% in Java). - Apiiro saw 3–4× more code produce 10× more security findings. - GitClear measured an 8× rise in duplicated code blocks and a 40% drop in refactoring. - On the other hand, a study of 37,623 public agent PRs found security-smell rates lower than humans' when pooled, with large differences between agent vendors. ![Veracode: 45% of AI code tasks introduced a vulnerability, Java >70%. Apiiro: 10× more security findings for 3–4× more code. GitClear: 8× more duplicated code blocks, −40% refactoring. A 37,623-PR study behind good gates found agent security-smell rates below humans.](https://f200.ai/media/editorial/cc4ff2dee260cd3d9dd9e69a674fcf945a64617d0a9eae4889bfee1b9e29db17.webp)Studies report security and maintainability risks, while a gated PR study found lower agent security-smell rates than humans. The lesson isn't "AI code is bad". It is: the outcome depends on the system the code goes through. The same agents, behind good gates, produce good results. Behind no gates, they produce volume. ## 7. AI is an amplifier Google's DORA research summarises two years of data in one sentence: "AI's primary role is that of an amplifier. It magnifies the strengths of high-performing organisations and the dysfunctions of struggling ones." Teams with clear policies, small batches, solid version control, good internal platforms and accessible data get the gains. Teams without them get more instability. DORA reports that throughput is up across the industry while delivery instability keeps rising. McKinsey reaches the same conclusion from the other side: top performers see 16–30% improvements in team productivity, customer experience and time to market, and 31–45% in software quality. What separates them is how they work, not which tools they bought. ![AI coding agents amplify strong foundations into faster, safer delivery, and weak foundations into more code and more instability.](https://f200.ai/media/editorial/50a7878c0e0b73f0cf06fdbef02ca59065eb00949d9e479483223b4485bff0cd.webp)AI is an amplifier This is why a software factory is a management decision, not a tooling decision. The factory is how you make your organisation the kind that AI amplifies upward. ## 8. Where the business value comes from ![Five branches of business value: throughput, lead time, quality and risk, cost control, and talent leverage, with the figures supplied in the brief.](https://f200.ai/media/editorial/1c3a11f40873106cec6666690dd42db61b59c33c4d9d5261287e4b3d0087139c.webp)Where the business value comes from For a CEO, the value of a software factory shows up in five places: - Throughput. More finished, merged work per engineer: +20–30% in controlled studies, +24% for agentic tools at Microsoft, with Gartner expecting agent-based workflows to reach 30–50% team gains versus 0–20% for assistants alone. - Lead time. Shorter time from idea to production, because the queue, verification and merge steps are automated and run around the clock. Google reports a large migration running "six times faster" with AI. - Quality and risk. Verification that can't be skipped, deterministic policy on dangerous actions, and an audit trail. This is what keeps the 45%-flawed-code statistic out of your production systems. - Cost control. Agent spend is real, and it is growing even as models get cheaper (see the next section). Budgets, model routing and avoiding wasted agent work are part of the factory. One 2026 study found simple developer-written "skills" cut agent cost by 8–42% in most settings. - Leverage of scarce talent. Your senior engineers stop typing and start specifying, reviewing and designing. The factory multiplies the people you can't hire more of. ![Cursor annualised revenue run-rate: $2B February 2026, $3B late April 2026, $4B+ June 2026; Claude Code >$2.5B early 2026. Gartner enterprise AI coding agent market ≈ $10–11B/year in 2026; 90% of enterprise engineers to use AI code assistants by 2028, from <14% early 2024.](https://f200.ai/media/editorial/7a586ddca2e9e5c1c7e5e10089682a02043227134be8e8b2fe49a6e0fbb8bdcc.webp)Reported coding-agent run-rates reached billions of dollars as Gartner forecast widespread enterprise adoption. The market is moving accordingly. Gartner published its first Magic Quadrant for Enterprise AI Coding Agents in May 2026 and sizes the market at roughly $10–11 billion a year. Claude Code alone passed a $2.5 billion run-rate in early 2026, and Cursor reported growth from $2 billion to over $4 billion run-rate between February and June 2026. Enterprises are paying for this, at scale. ## 9. The economics: cheaper tokens, bigger bills First, a paradox every CFO will meet: tokens get cheaper, bills get bigger. The price of a fixed level of AI capability falls roughly 10× a year (a16z) and by a median of 50× a year on Epoch AI's measures. Yet spend per developer is rising: Anthropic's own estimate of a typical Claude Code day went from about $6 to about $13 in a year, a quarter of technology leaders already spend $200–500 per developer per month (Gartner), and Gartner expects AI coding cost per engineer to exceed the average developer's salary by 2028. Cheaper intelligence means agents do longer, more autonomous work, and that work costs money. Gartner's warning is blunt: without a governed engineering operating model, costs can escalate faster than the productivity gains. ![Constant-capability cost per million tokens: $60 in 2021 to $0.06 in 2024, ~10× cheaper yearly (a16z); Epoch AI median 50× yearly. Claude Code typical cost per developer per active day: $6 in 2025 to $13 in 2026. A quarter of tech leaders spend $200–500 per developer per month. Uber exhausted its 2026 AI-coding budget in ~4 months. Gartner forecasts AI coding cost per engineer exceeding average developer salary by 2028.](https://f200.ai/media/editorial/1565a0b208829438335be163ee15ccf580a8483afe371f4adc147ff6e8113f8b.webp)Lower token prices coexist with rising bills. Budgets belong inside the factory. We won't give you a made-up ROI number. Here is the model we use with clients instead, so you can plug in your own figures. ![Engineer cost times measured throughput gain yields extra-output value. Subtract agent spend, review time and factory operation, then adjust for quality to find net quarterly team value.](https://f200.ai/media/editorial/0f8072cb79b17daa9e7636562a36709a06f610433ecd32454d8fa602861e3442.webp)A simple economic model (use your own numbers) - Start from the fully loaded cost of an engineer. The US median software developer wage alone is about $133,000 (BLS, 2024), before benefits and overhead. - Apply a measured, conservative throughput gain. 20–25% is what the controlled studies support for well-run teams. - Subtract the new costs. Agent and model spend, more review time, and the time to build and run the factory itself. - Adjust for quality. Escaped defects and security incidents cost far more than the code that caused them, so verification is worth paying for. Run the numbers per team, measure for a quarter, and decide with data. The METR study is the reason: if you rely on how productive people feel, you can be off by 40 points. ## 10. What this means at your stage The software factory looks different for a solo founder and for an enterprise. The principles are the same. ![Four growth stages compare constraints, initial factory capabilities and payoffs, with governance increasing from solo founder to enterprise.](https://f200.ai/media/editorial/a49a1a4acab16d10596d71da4e9644da4fe0ea19348b40d27063a874d862822c.webp)The software factory at every stage ### Solo founders and indie builders Solo founding is rising fast: the share of new startups with a single founder went from 23.7% in 2019 to 36.3% in the first half of 2025 (Carta). In Y Combinator's Winter 2025 batch, a quarter of companies had codebases that were about 95% AI-written. ![Solo founders accounted for 23.7% of new startups in 2019 and 36.3% in H1 2025. 25% of YC Winter 2025 had codebases ~95% AI-generated. Solo founders received 14.7% of priced-round cash in 2024.](https://f200.ai/media/editorial/87d0c9a15ca2808ac307f48d91d550f4db2217bf5278076d9a6359782414fd38.webp)The solo-founder share of new startups rose to 36.3% in H1 2025, while YC reported extensive AI-generated code in a quarter of its winter batch. The economics of small teams have changed. Base44, a bootstrapped company with one founder, was sold to Wix for $80 million in cash six months after launch. Lovable reported about $2.7 million of revenue per employee in early 2026, against a median of about $141,000 for private SaaS companies. Gartner expects 60% of organisations to run "tiny" software teams of two to five people by 2029, up from 15% in 2026, and warns that cutting junior roles weakens the talent pipeline. ![Revenue per employee: Lovable ~$2.7M (Feb 2026, company statement) versus median private SaaS $141K (2026, SaaS Capital). Base44: solo-founded, sold to Wix for $80M cash after 6 months (Jun 2025). Gartner forecast: organizations running tiny 2–5 person software teams rise from 15% in 2026 to 60% in 2029.](https://f200.ai/media/editorial/d71b7b565dff570a08eb38da6f26600d1c87ff0ba503e3ee2155b81e5940e4b9.webp)Lovable reports ~$2.7M revenue per employee; Base44 sold for $80M after six months; Gartner forecasts more tiny software teams. ![A single faceless founder at a helm beside a lighthouse directs identical boats along coordinated magenta courses across a nautical chart.](https://f200.ai/media/editorial/a25d3ae6722479ba1b3ec1ee65496c1eef53cff2c98ba34688a8f0a3cdc2f4e3.webp)One founder sets the course for a fleet of agents. For a solo founder, the factory is a force multiplier: you are the product owner, the reviewer and the release manager, and the agents are your team. What you need most: - A queue and small tasks, so agents work on the right thing in the right order. - Automatic verification, because you can't review everything by hand. - Budgets, because a runaway agent loop is your burn rate. - Memory, so you don't re-explain your product to every new session. ### Startups and scale-ups Your constraint is senior engineering time. The factory turns your best engineers into specifiers and reviewers and lets agents absorb implementation, migrations, tests and maintenance. Watch the review bottleneck most closely: if PRs pile up, add risk tiers (low-risk changes need one review, infrastructure needs more) rather than more reviewers. ### Enterprises Your constraint is risk and governance. You need policy as code, audit trails, approvals routed to the right people, spend caps per team, and evidence that controls work. The Gartner Magic Quadrant exists because this buyer exists. The factory is how you let hundreds of agents work without losing control of what reaches production. ## 11. How to start: a 90-day plan ![A three-phase roadmap: measure and pilot in days 1–30, add factory parts in days 31–60, and scale what the data supports in days 61–90, with data-driven checkpoints.](https://f200.ai/media/editorial/3a745ee9435964759d2cbec2b46c395ab196666a54a6f19c67ec81da901d3f27.webp)Your first 90 days Days 1–30: measure and pilot. Pick one team and one workflow, such as test writing, dependency upgrades or internal tools. Baseline the metrics you care about: lead time, merged work, escaped defects, review time and spend. Give agents sandboxed workspaces and a short list of things they may never do. Days 31–60: add the factory parts. Put work into a queue with small, well-defined items. Make verification mandatory: an agent's turn isn't finished until the declared checks pass. Introduce risk-tiered review and a merge pipeline that only merges the exact commit that was verified and reviewed. Set budgets. Days 61–90: scale what the data supports. Compare against the baseline. Expand to more teams only where the measured numbers moved. Add memory so agents stop repeating work. Report value in business terms: lead time, quality, cost per change. ![Boats follow two orderly magenta lanes between navy buoys through a harbour gatehouse with a green signal and an open logbook on the pier.](https://f200.ai/media/editorial/ffe18f4a102adc6d62855e3e614a2b25e3cb626d13c8f8ab9d911a821f0c83c0.webp)Governance provides clear lanes, permission signals, and a record of passage without slowing traffic. ## 12. The honest risks A software factory is not magic, and the research is clear about what can go wrong: - Perception is unreliable. Measure outcomes, not sentiment. - Review quality decays. Reviewers get used to approving agent work. Make verification automatic and keep human review focused where risk is high. - Security and maintainability. AI code can multiply vulnerabilities and duplication without the right gates. - Understanding. Developers who let agents do everything understand their code less. Keep people in the design and review loop. - Cost. Without budgets and routing, agent spend can grow faster than the value. Every one of these risks is a reason to build the factory, not a reason to avoid AI. The companies that will lose are the ones that adopt agents without the system around them. ## 13. How f200 approaches this We build and run AI software factories, for ourselves and for clients. Our own engineering has run on Shiftyard, our factory for coding agents, since October 2026. It is pre-release and will be open source under Apache-2.0; you can read the [technical deep-dive](https://f200.ai/blog/inside-shiftyard-governed-software-factory-for-coding-agents). For clients, our Software Factory Integration service designs and installs the queue, gates, verification, review and memory around the agents your teams already use. If you want to know what a software factory would mean for your company, at your stage, book a 30-minute call with the founders. We'll start with your workflow and your numbers, not with a tool. ## Sources - Peng et al., The Impact of AI on Developer Productivity: Evidence from GitHub Copilot, arXiv 2302.06590, Feb 2023. [https://arxiv.org/abs/2302.06590](https://arxiv.org/abs/2302.06590) - Paradis et al., How much does AI impact development speed? An enterprise-based randomized controlled trial, arXiv 2410.12944, Oct 2024. [https://arxiv.org/abs/2410.12944](https://arxiv.org/abs/2410.12944) - Cui, Demirer, Jaffe, Musolff, Peng, Salz, The Effects of Generative AI on High-Skilled Work, Management Science, 2025. [https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4945566](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4945566) - METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, Jul 2025; and uplift update, Feb 2026. [https://metr.org/Early_2025_AI_Experienced_OS_Devs_Study-paper.pdf](https://metr.org/Early_2025_AI_Experienced_OS_Devs_Study-paper.pdf) · [https://metr.org/blog/2026-02-24-uplift-update/](https://metr.org/blog/2026-02-24-uplift-update/) - Murphy-Hill, Butler, Savelieva (Microsoft), Adoption and Impact of Command-Line AI Coding Agents, arXiv 2607.01418, Jul 2026. [https://arxiv.org/abs/2607.01418](https://arxiv.org/abs/2607.01418) - Faros AI, Lab vs. Reality: AI productivity study findings, Jul 2025. [https://www.faros.ai/blog/lab-vs-reality-ai-productivity-study-findings](https://www.faros.ai/blog/lab-vs-reality-ai-productivity-study-findings) - Google DORA, State of AI-assisted Software Development 2025, Sep 2025. [https://dora.dev/research/2025/dora-report/](https://dora.dev/research/2025/dora-report/) - Stack Overflow, 2025 Developer Survey (Jul 2025) and survey look-back (Sep 2026). [https://survey.stackoverflow.co/2025/](https://survey.stackoverflow.co/2025/) · [https://stackoverflow.blog/2026/09/30/getting-ready-for-2026-results-a-look-back-on-developer-survey-findings/](https://stackoverflow.blog/2026/09/30/getting-ready-for-2026-results-a-look-back-on-developer-survey-findings/) - JetBrains, State of Developer Ecosystem 2025, Oct 2025. [https://blog.jetbrains.com/research/2025/10/state-of-developer-ecosystem-2025/](https://blog.jetbrains.com/research/2025/10/state-of-developer-ecosystem-2025/) - GitClear, AI code quality report, Feb 2025. [https://gitclear-public.s3.us-west-2.amazonaws.com/GitClear-AI-Copilot-Code-Quality-2025.pdf](https://gitclear-public.s3.us-west-2.amazonaws.com/GitClear-AI-Copilot-Code-Quality-2025.pdf) - Veracode, 2025 GenAI Code Security Report, Jul 2025. [https://www.veracode.com/resources/analyst-reports/2025-genai-code-security-report/](https://www.veracode.com/resources/analyst-reports/2025-genai-code-security-report/) - Apiiro, 4x Velocity, 10x Vulnerabilities, Sep 2025. [https://apiiro.com/blog/4x-velocity-10x-vulnerabilities-ai-coding-assistants-are-shipping-more-risks/](https://apiiro.com/blog/4x-velocity-10x-vulnerabilities-ai-coding-assistants-are-shipping-more-risks/) - METR, time-horizon benchmark results v1.1 (accessed Oct 2026). [https://metr.org/time-horizons/](https://metr.org/time-horizons/) - OpenAI, Why we no longer evaluate SWE-bench Verified, Feb 2026. [https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified/](https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified/) - Stanford HAI, 2026 AI Index Report. [https://hai.stanford.edu/ai-index/2026-ai-index-report](https://hai.stanford.edu/ai-index/2026-ai-index-report) - Gartner, software engineering trends press release, Jul 2025; Magic Quadrant for Enterprise AI Coding Agents, May 2026 (as reported by Virtualization Review). [https://www.gartner.com/en/newsroom/press-releases/2025-07-01-gartner-identifies-the-top-strategic-trends-in-software-engineering-for-2025-and-beyond](https://www.gartner.com/en/newsroom/press-releases/2025-07-01-gartner-identifies-the-top-strategic-trends-in-software-engineering-for-2025-and-beyond) · [https://virtualizationreview.com/articles/2026/06/05/ai-firms-push-cloud-giants-from-leaders-quadrant-in-gartner-ai-coding-report.aspx](https://virtualizationreview.com/articles/2026/06/05/ai-firms-push-cloud-giants-from-leaders-quadrant-in-gartner-ai-coding-report.aspx) - McKinsey, Unlocking the value of AI in software development. [https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/unlocking-the-value-of-ai-in-software-development](https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/unlocking-the-value-of-ai-in-software-development) - Google, Cloud Next 2026 keynote remarks on AI-generated code (as reported by The Decoder). [https://the-decoder.com/google-says-75-percent-of-its-new-code-is-now-written-by-ai/](https://the-decoder.com/google-says-75-percent-of-its-new-code-is-now-written-by-ai/) - Anthropic, Series G announcement, Feb 2026. [https://www.anthropic.com/news/anthropic-raises-30-billion-series-g-funding-380-billion-post-money-valuation](https://www.anthropic.com/news/anthropic-raises-30-billion-series-g-funding-380-billion-post-money-valuation) - Cursor revenue run-rate, Dealroom, Jun 2026. [https://dealroom.co/news/134107-cursor-tops-4b-annualized-revenue/](https://dealroom.co/news/134107-cursor-tops-4b-annualized-revenue/) - TechCrunch, Y Combinator W25 AI-generated codebases, Mar 2025. [https://techcrunch.com/2025/03/06/a-quarter-of-startups-in-ycs-current-cohort-have-codebases-that-are-almost-entirely-ai-generated/](https://techcrunch.com/2025/03/06/a-quarter-of-startups-in-ycs-current-cohort-have-codebases-that-are-almost-entirely-ai-generated/) - Carta, Solo Founders Report 2025, Dec 2025. [https://carta.com/data/solo-founders-report/](https://carta.com/data/solo-founders-report/) - US Bureau of Labor Statistics, Occupational Outlook Handbook: Software Developers. [https://www.bls.gov/ooh/computer-and-information-technology/software-developers.htm](https://www.bls.gov/ooh/computer-and-information-technology/software-developers.htm) - Habituation at the Gate, arXiv 2606.22721, 2026. [https://arxiv.org/abs/2606.22721](https://arxiv.org/abs/2606.22721) - Kraishan, agent PR security and maintenance study, arXiv 2609.17598, 2026. [https://arxiv.org/abs/2609.17598](https://arxiv.org/abs/2609.17598) - Purdue agent cost study, arXiv 2609.30725, 2026. [https://arxiv.org/abs/2609.30725](https://arxiv.org/abs/2609.30725) - GitHub, Octoverse 2025, Oct 2025. [https://octoverse.github.com/](https://octoverse.github.com/) - GitHub API, star counts for open-source coding-agent repositories, 8 Oct 2026. [https://api.github.com/repos/anomalyco/opencode](https://api.github.com/repos/anomalyco/opencode) · [https://api.github.com/repos/anthropics/claude-code](https://api.github.com/repos/anthropics/claude-code) · [https://api.github.com/repos/openai/codex](https://api.github.com/repos/openai/codex) · [https://api.github.com/repos/google-gemini/gemini-cli](https://api.github.com/repos/google-gemini/gemini-cli) · [https://api.github.com/repos/OpenHands/OpenHands](https://api.github.com/repos/OpenHands/OpenHands) · [https://api.github.com/repos/FoundationAgents/MetaGPT](https://api.github.com/repos/FoundationAgents/MetaGPT) · [https://api.github.com/repos/cline/cline](https://api.github.com/repos/cline/cline) · [https://api.github.com/repos/block/goose](https://api.github.com/repos/block/goose) · [https://api.github.com/repos/Aider-AI/aider](https://api.github.com/repos/Aider-AI/aider) · [https://api.github.com/repos/continuedev/continue](https://api.github.com/repos/continuedev/continue) · [https://api.github.com/repos/OpenBMB/ChatDev](https://api.github.com/repos/OpenBMB/ChatDev) · [https://api.github.com/repos/Kilo-Org/kilocode](https://api.github.com/repos/Kilo-Org/kilocode) · [https://api.github.com/repos/RooCodeInc/Roo-Code](https://api.github.com/repos/RooCodeInc/Roo-Code) · [https://api.github.com/repos/SWE-agent/SWE-agent](https://api.github.com/repos/SWE-agent/SWE-agent) · [https://docs.github.com/en/rest/repos/repos#get-a-repository](https://docs.github.com/en/rest/repos/repos#get-a-repository) - McKinsey, Technology Trends Outlook 2026, Sep 2026 (as reported by CIO Dive). [https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/the-top-trends-in-tech](https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/the-top-trends-in-tech) - Stripe Engineering, Minions: Stripe's one-shot, end-to-end coding agents, Feb 2026. [https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents-part-2](https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents-part-2) - Airbnb Tech Blog, test migration case study, Mar 2025. [https://medium.com/airbnb-engineering/accelerating-large-scale-test-migration-with-llms-9565c208023b](https://medium.com/airbnb-engineering/accelerating-large-scale-test-migration-with-llms-9565c208023b) - AWS DevOps Blog, Amazon Q Developer just reached a $260 million dollar milestone, Aug 2024. [https://aws.amazon.com/blogs/devops/amazon-q-developer-just-reached-a-260-million-dollar-milestone/](https://aws.amazon.com/blogs/devops/amazon-q-developer-just-reached-a-260-million-dollar-milestone/) - Uber Engineering, uReview, Aug 2025; The Pragmatic Engineer, How Uber uses AI for development, Mar 2026; Fortune, May 2026. [https://www.uber.com/gb/en/blog/ureview/](https://www.uber.com/gb/en/blog/ureview/) · [https://newsletter.pragmaticengineer.com/p/how-uber-uses-ai-for-development](https://newsletter.pragmaticengineer.com/p/how-uber-uses-ai-for-development) · [https://fortune.com/2026/05/22/microsoft-ai-cost-problem-tokens-agents/](https://fortune.com/2026/05/22/microsoft-ai-cost-problem-tokens-agents/) - Amplifying, State of the Coding Agent Market, Oct 2026. [https://amplifying.ai/research/state-of-coding-agents](https://amplifying.ai/research/state-of-coding-agents) - Takerngsaksiri et al., follow-up fixes after agent merges, arXiv 2609.26847, Sep 2026. [https://arxiv.org/abs/2609.26847](https://arxiv.org/abs/2609.26847) - SWE-chat, Stanford, arXiv 2604.20779, Apr 2026. [https://arxiv.org/abs/2604.20779](https://arxiv.org/abs/2604.20779) - Atlassian, State of Developer Experience 2025. [https://www.atlassian.com/teams/software-development/state-of-developer-experience-2025](https://www.atlassian.com/teams/software-development/state-of-developer-experience-2025) - a16z, LLMflation, Nov 2024; Epoch AI, LLM inference price trends. [https://a16z.com/llmflation-llm-inference-cost/](https://a16z.com/llmflation-llm-inference-cost/) · [https://epoch.ai/data-insights/llm-inference-price-trends](https://epoch.ai/data-insights/llm-inference-price-trends) - Anthropic, Claude Code cost documentation. [https://code.claude.com/docs/en/costs](https://code.claude.com/docs/en/costs) - Gartner press releases on AI coding costs (Jun 2026) and tiny software teams (Jul 2026). [https://www.gartner.com/en/newsroom/press-releases/2026-06-24-gartner-predicts-ai-coding-costs-will-surpass-average-developer-salary-by-2028-as-token-consumption-surges](https://www.gartner.com/en/newsroom/press-releases/2026-06-24-gartner-predicts-ai-coding-costs-will-surpass-average-developer-salary-by-2028-as-token-consumption-surges) · [https://www.gartner.com/en/newsroom/press-releases/2026-07-07-gartner-predicts-60-percent-of-organizations-will-adopt-smaller-software-engineering-teams-by-2029](https://www.gartner.com/en/newsroom/press-releases/2026-07-07-gartner-predicts-60-percent-of-organizations-will-adopt-smaller-software-engineering-teams-by-2029) - SaaS Capital, revenue-per-employee benchmarks for private SaaS companies. [https://www.saas-capital.com/blog-posts/revenue-per-employee-benchmarks-for-private-saas-companies/](https://www.saas-capital.com/blog-posts/revenue-per-employee-benchmarks-for-private-saas-companies/) - TechCrunch, Wix acquires Base44, Jun 2025. [https://techcrunch.com/2025/06/18/6-month-old-solo-owned-vibe-coder-base44-sells-to-wix-for-80m-cash/](https://techcrunch.com/2025/06/18/6-month-old-solo-owned-vibe-coder-base44-sells-to-wix-for-80m-cash/) - Company statements on AI-generated code share, as reported: Google (Apr 2026), Robinhood (Jul 2025), Coinbase (2025), Microsoft (Apr 2025), Uber (May 2026). [https://the-decoder.com/google-says-75-percent-of-its-new-code-is-now-written-by-ai/](https://the-decoder.com/google-says-75-percent-of-its-new-code-is-now-written-by-ai/) · [https://www.aol.com/robinhood-ceo-says-majority-companys-094801868.html](https://www.aol.com/robinhood-ceo-says-majority-companys-094801868.html) · [https://www.theblock.co/news/business/2025-09-04-brian-armstrong-coinbase-ai-369460](https://www.theblock.co/news/business/2025-09-04-brian-armstrong-coinbase-ai-369460) · [https://techcrunch.com/2025/04/29/microsoft-ceo-says-up-to-30-of-the-companys-code-was-written-by-ai/](https://techcrunch.com/2025/04/29/microsoft-ceo-says-up-to-30-of-the-companys-code-was-written-by-ai/) · [https://fortune.com/company/uber-technologies/earnings/q1-2026/](https://fortune.com/company/uber-technologies/earnings/q1-2026/)