# From working prototype to dependable system

> Architecture, access control, evaluation, agents, deployment and production integration for technically demanding teams.

Canonical URL: https://marmation.com/review/engineering/

AI engineering is often defined by the decisions that never appear in a demo. An agent must be prevented from taking the wrong action. Retrieval must obey permissions. Model versions must be evaluated. An integration must reconcile a successful transaction even after a timeout.

## How to use this collection

The Engineering collection studies those systems concerns in concrete terms, including where a packaged platform is better than a bespoke implementation. We prefer readable diagrams, explicit trust boundaries and negative tests over ungrounded claims of autonomy.

Use the articles as thinking tools, not as product advertisements. Start with the question nearest your current decision, follow the cited sources and inspect the limitations. Each article should tell you what to do differently, when the recommendation changes, and which risks cannot be resolved by reading alone.

## Talk to an engineer, not a form letter

If the decision leads to a real engineering assignment, share the relevant requirements and constraints. Marmation can help determine whether a focused engagement is appropriate. [Discuss a project](<https://marmation.com/contact/>).

## Related reading

- [Design the action boundary before designing the agent.](https://marmation.com/review/designing-an-agent-with-bounded-actions/)
- [Engineering autonomy is a control design problem.](https://marmation.com/review/engineering-autonomy-is-a-control-design/)
- [Fine-tuning, RAG or prompting: ask what needs to change.](https://marmation.com/review/fine-tuning-versus-rag-versus-prompting/)
