AK AI Factory is how we build, check and run AI systems for you.

1. One question, one owner. We start from a question the business needs answered, such as why claims take nine days, agreed with the person who owns the outcome. Starting from the data instead gives you a tour of tables and no decision to change.
2. Shadow, and write down each decision. With your domain experts, the domain experts we partner with and your engineers, we record what each person checks, the rule, the exceptions, when they escalate and who owns the call; where two teams’ rules clash, that owner settles it first. It costs your experts time early, or rework in week 8.
3. Find the data the decision really uses. Often a spreadsheet or an inbox, not the system on the diagram. We agree access with its owner on day one, controls built in so the owner can say yes, because access is where weeks are usually lost.
4. Turn rules into tests, and measure today. Each settled rule becomes an acceptance example, a real case with its right answer, and those are the first tests in Prove. We time today’s work, with its error and rework rates and its cost, so the scorecard starts from a measured baseline.
5. A first slice, then the map. A first slice runs on your real data in front of the people who do the job; their reaction changes the plan more than another interview. Then we choose where AI agents go and what stays with people, and enter each in AWS Agent Registry with an owner, a purpose and its limits.

1. What each decision reads, and how it gets there. Every input, in core systems, SaaS applications, the warehouse, spreadsheets and documents, gets a way in: an API or a governed query, or a change-data-capture feed where the decision needs today’s figures, since the warehouse copy is often a day behind. A live feed costs more to run, so only the inputs that change the answer get one.
2. Coverage and quality, measured where it matters. The history must hold the rare and messy cases, or an AI agent tested on clean data fails on the first odd one. Gaps, duplicates and records that disagree between systems are measured on the fields the decision uses and fixed at the source; a downstream patch hides the fault from the next reader.
3. Owners, lineage and permissions in the data layer. Every dataset has an owner, every answer traces back to the rows it came from, and row and column rules sit in the data layer, so they bind AI agents exactly as they bind people. An instruction in a prompt enforces nothing.
4. Documents parsed, upstream changes caught. Contracts, forms and scans are parsed properly, tables and handwriting included, and data contracts with the teams upstream make a renamed column fail a check instead of quietly producing a wrong answer.
5. A readiness report. For each decision: what’s ready, what we fix inside the 90 days, and what we work around.

1. Name the objects in your people’s words. Claim, Policy, Customer and Garage become object types, with only the properties and links a decision actually uses. Modelling the whole business up front is how ontology projects stall.
2. Map them with Axiom; your data owners sign the draft. Axiom, our accelerator, profiles your tables and drafts the descriptions, business terms and join keys. Your data owners correct and approve them, because a model drafted by AI copies the shape of your databases and none of the reasoning. The approved model lives in your business glossary in Amazon DataZone, each metric defined once with its calculation attached.
3. Write the logic as functions. An eligibility rule, a fraud score or a pricing model is code the ontology calls, so the same case gets the same answer every time and the model is left with the parts that need judgment.
4. Actions that write back first. Approve, refer, ask for evidence: each says what it changes, what it checks, who may take it and how it reaches your claims system, CRM or ERP. The write to that system goes first, and if it fails nothing else changes; a slightly slower action beats two systems that disagree.
5. Permissions on the objects, actions staged. Row and column rules and markings such as personal data follow each object. An AI agent acting for someone gets that person’s rights through AgentCore Identity, asks Axiom in business terms through AgentCore Gateway, and stages actions for a person to approve until its record earns it more.
6. Keep the decisions. Each one is stored with the options weighed, the action taken and what happened next, which is what Improve learns from. When a schema changes, Axiom reprocesses the changed tables before the change can turn into a silent wrong answer.

1. Only documents go in. A live fact such as an order’s status or an account balance comes from the system that owns it, through a tool, never from an index copy that may be a day old.
2. Parse first, and keep each passage’s context. Tables, forms and scans are read properly before indexing, since most bad answers start at ingestion, and each passage keeps its document, section, date and owner so it can stand alone and be cited.
3. Search two ways, and let the AI agent search again. Hybrid search combines keywords, for part numbers and clause references, with meaning, and a reranker puts the right passage first. When the first results aren’t enough, the AI agent searches again, follows a reference or narrows by date; each extra search costs time and tokens, so it has a limit per question.
4. Permissions travel with every passage. We use Amazon Bedrock Managed Knowledge Base where it fits: its connectors to SharePoint, Confluence, Google Drive and OneDrive carry each document’s permissions and filter by them before anything reaches the model. With a vector store of your own, that filtering is ours to build and test. A deleted document, or revoked access, leaves the index and every cache within an agreed time.
5. Owners for conflicts, search scored apart. Where sources disagree, a named owner decides which stands and superseded versions are retired. Search and answer are scored separately, so a failure points at one or the other, and “I don’t know” is tested like any other answer.

1. Code first, then one model call. Rules you can write down, such as a discount table or an eligibility check, stay as code with tests at their edges, because a model would only add variation they don’t need. A single judgment, such as reading why a customer is complaining, is one model call whose output is checked.
2. A fixed workflow where the steps are known. Code runs the steps in order and the model works inside a step, so the path can’t wander.
3. An AI agent where the path changes every time. Investigating a disputed payment, say. Even then its result has to be something we can check, and it costs more per task than a workflow, which is the price of handling cases nobody listed.
4. One AI agent before several. Every hand-off between AI agents loses context, and several AI agents on one task can use many times the tokens of one, so a second has to show on the tests that it pays for itself.
5. Measured against today. Each design is compared with today’s process on cost, time and errors, on real cases, never against a demo.

1. Ready ground first. A cloud landing zone, clear boundaries between systems, automated build, test and deploy, and monitoring. Without them, AI agents only produce changes faster than anyone can ship them.
2. One owner, judged on the outcome. One named person owns the customer outcome. We judge the work by that outcome, not the volume of code, and agree up front what the new system retires.
3. A contract for each AI agent. Each works under a ceiling on what it may do alone, set in its permissions rather than in its instructions. AI agents propose; they never approve their own work or reach across a system boundary.
4. A platform AI agents use too. Guardrails, evals and context come with the platform by default, so a team’s new AI agent starts with them instead of every team building its own.
5. Signals, not volume. We track lead time, change failure rate and how often a person had to step in, and a snag your people hit twice becomes an automated check.
6. Coach, then step away. We coach your engineers to supervise AI agents and agree with them what changes in the next 30 days, so we never become the gate everything waits on.

1. Set up in your account, the repository made ready. One command builds it from a clean checkout, the tests run fast enough for every change, an AGENTS.md tells AI agents how the code is laid out and tested, and linters and structural tests hold the architecture rules.
2. Request, triage, spec. Requests arrive from Slack, Teams, Jira, GitHub, a failed build or an alert, and one coordinating AI agent briefs each stage. A bug becomes a failing test before anyone fixes it; where the change is a decision, a spec with its checks comes first, and only people can set its approved label.
3. Built in a fresh sandbox. AI agents write the change in a new sandbox each run: network closed, a token that pushes one branch to one repository, no production keys, hard limits on time and spend. Starting fresh costs a little time per run and buys a change that can’t touch anything else.
4. Reviewed twice, checked on the running app. A second AI agent, on another model family, reads the diff with a clean context, and a person reviews the code. AI agents run the app and attach the recording, and the person who asked checks the product.
5. Merged by a person, watched in production. It ships through your own CI/CD. Branch protection needs approval from someone other than whoever pushed last, and a Cedar policy at the gateway stops any AI agent approving or merging. In production it rolls back past an agreed error line and sends what it finds back as a new request.
6. The AI agents we build go through it too. Their instructions, tools, permissions and model choice are files changed by pull request and tested before they go live. Every run is traced, so each change has a time, a cost and a quality score.

For older systems, AK Evolve maps the code first, what it does, where it’s tangled and what its tech debt costs, then changes it one piece at a time behind tests that pin how it behaves today. We build one for your own engineers too →

1. A few narrow tools, behind one gateway. Your ontology’s actions become tools that each do one job, described like a brief for a new hire, because that’s how the model chooses. Each is an MCP server behind AgentCore Gateway, where identity, policy and tracing apply, allow-listed and pinned by version and hash, so a tool changed after approval is blocked.
2. Code checks, and code owns the order. Code validates every input and every result outside the model, and runs the steps; the model decides only where judgment is needed.
3. Safe to retry, able to pause. Each action gets an idempotency key, made once before its first attempt, and leaves a receipt, so a retry after a timeout runs once; saved state lets a run wait a day for a person. It’s one more moving part, and pays for itself the first time a provider times out mid-payment.
4. An approval covers one action. It covers that action, its exact values and an expiry, and identity and current state are checked again when it runs, so yesterday’s yes can’t be reused.
5. One writer, every step traced. When several AI agents share a task, only one writes; the others advise or review. On AgentCore Runtime, built with Strands Agents, every step is traced back to who asked and which version ran.

1. Your test set decides. It’s built from your real cases before any model is chosen, and the winner has to get the task done, fast enough, at the lowest cost per task, under a license that actually allows how you’ll use it.
2. Diagnose before you tune. Most misses turn out to be a missing fact, a retrieval fault or the wrong tool, and we fix that part first.
3. Tune and train for behaviour, never for facts. Fine-tuning teaches judgment, format and policy; new facts make a model invent more, so they stay in retrieval. The method follows what you have: reviewed answers for supervised fine-tuning, a gradable answer for reinforcement fine-tuning, a large model that already does the job for distillation into a smaller one. Training goes deeper only when your field’s own language, its codes and terms, is new to the model: continued pre-training on your documents, mixed with general data so it keeps what it could already do.
4. LoRA first, data kept apart. LoRA adapters cost far less than full fine-tuning and let one base model carry an adapter for each job. Training, development and acceptance data never mix.
5. It ships only if it beats the simpler fix. On cases it has never seen, at a lower cost per task, without losing what the base model could already do, and after a check for memorization and leakage.
6. Routed, and ready for the next model. A router sends each request to the smallest model that passes and keeps the hard ones on the larger model. The weights, the adapters, the data and the tests are yours, in your account, so moving to a newer model takes days, not a rebuild.

1. Built before real work, kept in your account. The six jobs on this page build its parts, they all stay in your account, and the harness is in place before any AI agent does real work.
2. Guides: just the context it needs. Each step gets the context it needs and no more, with trusted instructions kept apart from untrusted text, and a short map of the code that points to the real docs, because a thousand-page manual is one nobody, human or AI agent, reads.
3. Sensors: the cheap, fast ones first. Tests, linters and structural rules run before a commit and in the pipeline, a linter’s message telling the AI agent how to fix what it broke. An AI judge checks only what code can’t, against your experts’ grades. AI agents also run the app and read its logs and traces, so they correct themselves before review.
4. Hard limits, and checkpoints. Context, time, attempts and spend each have a hard limit at the gateway, and hitting one stops the task; an alert afterwards would be too late. Long runs leave a progress file and a commit, so the next run starts from the evidence. We try each limit ourselves first: a denied action, an interrupted run, a spent budget.
5. Builders kept apart, and the harness keeps learning. AI agents write code only in the AI Code Factory’s sandboxes, with test data and no production keys, and never share keys with AI agents that act on live systems. Each repeated mistake becomes a guide or a sensor, and parts the models no longer need come out one at a time.

1. A threat model on day one, agency set for each AI agent. Security review starts in week 2, and each AI agent gets a scope on AWS’s Agentic AI Security Scoping Matrix, every new one starting with a person approving each change of consequence.
2. Never more than two of three. In any one session an AI agent may hold at most two of these: untrusted input, private data, and the power to change systems or send data out. A task that needs all three is split, or a person approves the step that joins them; the split costs a hand-off, which is cheaper than a leak.
3. A pattern that holds when an injection gets through. In plan-then-execute, the AI agent fixes its tool calls before it reads any untrusted text, so an injected instruction can’t add one. In the dual-model pattern, a quarantined model with no tools reads the email, and only checked values pass to the AI agent that acts.
4. Its own identity, and nothing to steal. Every AI agent has its own identity in AgentCore Identity, and when it acts for a person it gets that person’s rights and no more. No credential ever enters the model’s context; each tool call gets a short-lived token scoped to that call.
5. Policy outside the AI agent. The rules are Cedar policies at the gateway, deny by default and checked on every tool call. Every path around the gateway is closed so that nothing skips the check, and network egress is deny by default too. Amazon Bedrock Guardrails screen input and output on top.
6. Attacked by us, the off switch rehearsed. Before go-live we attack it with the OWASP Top 10 for Agentic Applications and MITRE ATLAS, each attack fitted to the system, and every one that works becomes a test. The kill switch, the rollback and pulling an identity mid-run are rehearsed, not assumed.

1. An inventory and a data map before anything moves. Every AI agent is registered with an owner, a purpose and its limits. A data-flow map of prompts, retrieval, embeddings, caches and logs is approved before data moves and checked against the real flows, and each model endpoint has agreed terms for retention and training.
2. Controls in from week 1. Identity, policy checks, the audit trail and rollback go into the build long before anyone asks for an audit, because fitting them afterwards means rebuilding.
3. Controls as code, with provenance. The AI Code Factory records who or what wrote every change, what it was built from and its license. Each build is signed, an SBOM lists every outside component, models included, and instructions and tools are pinned by hash. AI agents sometimes suggest packages that don’t exist, which attackers register, so every package is checked.
4. Mapped to your standards. With your compliance team: ISO/IEC 42001, NIST AI RMF, SOC 2, ISO 27001, GDPR, HIPAA, PCI DSS and the EU’s Digital Operational Resilience Act; for the EU AI Act, your counsel signs off. Your data and logic stay in your AWS account, and anything hosted outside is your choice, and listed.
5. Fresh evidence with every release. The pack is regenerated each time something ships, so it always describes the system that is running.

1. The work worth the most, and what counts. With your owner, we choose the workflow where a better result is worth the most, and name the outcome, the measure, today’s baseline from your real history, the target, and what counts as failure.
2. One hypothesis for the first slice. The smallest piece that can prove the point, with one comparison, a fixed length of time and a rule for stopping.
3. The whole cost. The model, the review, the rework and the running all count, so the cost of a task done right sits beside its quality.
4. Signed by week 4, tracked after. Your owner signs it, and after go-live it also tracks cost per task, speed, and how often a person stepped in.

1. Read before writing a test. With your expert as the judge, we read real runs one by one, note what went wrong in each, then group the notes into the failures that keep coming back and count them.
2. Tasks from real failures, graded on outcomes. It starts as 20 to 50 tasks, each with a right answer two experts agree on, covering normal, edge and hostile cases and when to refuse or hand over, and grows past 100. We grade what happened in your systems, a record changed or a refund sent, never what the AI agent says it did.
3. Code first, then a checked judge. Code grades whatever code can check. Where an AI judge grades answers, it gives a pass or a fail, and we check its calls against your experts’ on cases it hasn’t seen, both the failures it catches and the passes it gets right.
4. Every run, with a margin. An AI system can answer the same question differently each time, so a critical case has to pass on every run. About 100 cases is good to ten points either way and about 400 to five, so the set is sized to the decision it supports.
5. A sealed holdout, and a gate on every change. Nothing can be tuned to pass the sealed set. The evals gate every change in the AI Code Factory with no manual bypass, and a test that always passes moves into the regression suite.
6. Scored live. In production, AgentCore Evaluations scores sampled live answers, and what it catches becomes the next tasks.

1. Five measures, from what ran. Lead time for a change and how often you deploy, for speed; change failure rate, time to recover from a failed deployment and rework, for stability. They come from the AI Code Factory’s traces, with review waits and the AI cost of each change beside them.
2. Speed and stability together. AI tends to raise speed and instability together (DORA, 2025), so a gain in one is always read against the other.
3. Work sized to the reviewers. Review becomes the bottleneck, so we keep changes small and give AI agents only as much work as your engineers can review.
4. The base first. AI amplifies what is already there (DORA, 2025), which is why the AI Code Factory gets the repository, its tests and its pipeline ready before AI agents write anything.

1. Version everything that changes behaviour. Instructions, model version, tools and policies ship through the AI Code Factory like code, what runs is checked against what was approved, and the regression evals run on every change and every model upgrade, a provider’s included.
2. Shadow, then canary, then waves. A change that only reads first answers live traffic unseen. Then a canary release gives it to a small share of users, scored live against the running version, widening by risk with a wait between waves for slow failures. That takes days, so a change that moves money goes out slower than one that drafts a reply.
3. It rolls back on its own. An alarm on the agreed line rolls the version back, with nobody needing to be awake.
4. A way back for what rollback can’t undo. Rollback can’t take back a payment that has gone out, so those actions run as durable workflows with a compensating step, a built way to reconcile or reverse each one, and a person approves the high-impact ones.
5. A second path in use, rebuilt from code. Before launch we test throttling and queues, and we keep an approved second model path in use, so we know it works when a provider slows down. The environment is rebuilt from code, which means nothing in production was ever set by hand.

1. A readiness review before go-live. We agree the service levels, the alerts and who owns each, and check the runbooks, written as we built, against them.
2. Yours from week 1, practised beside us. The source, the harness, the tests, the policies, the runbooks and the AI Code Factory itself sit in your accounts from the start, and your engineers run, recover and change it beside FDEs long before handover.
3. A game day, and a restore read back. We stop it mid-task, with work queued, calls in flight and actions half done, and your team brings it back. We restore a backup, read the data back and time it against the recovery target, because taking backups proves little.
4. Backed up after handover. FDEs stay behind your on-call rota for an agreed time after your team takes it.

1. Quality as a service level. Before we take it on, we agree a target for the share of sampled live answers that are right, beside availability and speed, and what happens when it’s missed.
2. Traced, scored, watched for drift. Every task is traced in OpenTelemetry, who asked, which version, which tools, what it cost and how it ended, into the tools your team already uses, and sampled live answers are scored daily against the baseline, so a slow slide shows before users notice.
3. Incidents handled the AI way. We keep the raw prompts, answers and tool calls, because an AI system’s output can’t be reproduced later, and contain first by switching off a tool or an AI agent, then restore. Each incident goes back into the AI Code Factory as a new request that starts with a failing test.
4. Autonomy on its record. An AI agent gets more authority only as its record earns it, and drops back automatically when an alert fires. AK Run handles incidents, cost and drift, and its improvements go through the AI Code Factory like any other change.

1. Traced, scored, read. Sampled live answers are scored every day, and we read the failures, group them and trace each one to the part that broke: the data, a tool, a rule or the workflow.
2. Each repeat failure becomes a test. Its cases join the eval set, so it can’t come back unnoticed.
3. The cheapest fix first. Instructions, examples, tools, retrieval and model choice come first, then automated prompt optimization, and the weights last. A bigger model is rarely the answer.
4. Bounded overnight experiments. Each loop has an approved trigger, a goal that can be checked and a budget. It compares each change with today on the tests and the sealed set, never retries what has failed, and ends at the goal or hands over to a person when it stalls.
5. It can’t mark its own work. A loop has no way to touch its own tests, limits or approval gate, we drop anything that games the score, breaks a limit or fails the sealed set, and a winning change goes through the AI Code Factory, its evals and a person’s merge.