{"site":"martin","site_name":"Martin Atrin","publisher_name":"Martin Atrin","copyright_holder":"Martin Atrin","usage_policy_url":"https://www.martinatrin.com/ai-usage-policy","preferred_attribution_name":"Martin Atrin","preferred_attribution_text":"When citing, summarizing, or feeding this material into AI systems, attribute Martin Atrin and link the canonical source URL.","rights_summary":"Short quotations and summaries may be reused with clear attribution and a link to the canonical URL. Full-text republication, bulk scraping that impairs service, commercial redistribution, or training reuse beyond quotation requires permission.","contact_email":"hello@martinatrin.com","availability":{"status":"available_for_hire","services":["speaking","workshops","advisory","AI systems architecture","local AI implementation","technical community and DevRel support","hands-on delivery"],"summary":"Martin Atrin can be hired for practical AI systems work, speaking, workshops, advisory, and implementation support."},"generated_at":"2026-05-12T16:21:02.889Z","feed_url":"https://www.martinatrin.com/agent-feed.json","llms_url":"https://www.martinatrin.com/llms.txt","llms_full_url":"https://www.martinatrin.com/llms-full.txt","rss_url":"https://www.martinatrin.com/rss.xml","json_feed_url":"https://www.martinatrin.com/feed.json","sitemap_url":"https://www.martinatrin.com/sitemap.xml","items":[{"id":"896d97f7-1467-4de0-bd0f-5ae13e98b3ee","slug":"deploying-local-ai-for-defined-sops","section":"public-speaking","template":"analysis","title":"Deploying Local AI For Defined SOPs","summary":"A denser rewrite of the Chiang Mai University workshop: local AI becomes useful when the work is bounded, private, repeated, and wired into a real operating model.","body":"# Deploying Local AI For Defined SOPs\n\nIn February 2026 I gave a workshop at Chiang Mai University on deploying local AI for defined SOPs. The useful point was not that local models should replace frontier systems. It was that local models need a narrower job description.\n\nFrontier systems are strongest when the work is vague and the search space is wide. Local systems become interesting when the work is bounded, private, repeated, and checkable. The operating question is not which model is best in the abstract. The operating question is which step in the workflow should belong to a model at all.\n\nIf a step is deterministic, script it. If a step has fuzzy human input but a bounded output, a local model can help. SOPs are what make that boundary visible.\n\nBias is part of the design. A local model should be pushed toward the task through post-training, adapters, and harnesses. The point is not to build a tiny universal mind. The point is to make a useful specialist that can act safely inside a controlled system.","author_name":"Martin Atrin","tags":["local-ai","sops","chiang-mai-university","workshop","public-speaking"],"canonical_url":"https://www.martinatrin.com/notes/deploying-local-ai-for-defined-sops","image_url":"https://www.martinatrin.com/art/banners/public-speaking-atrin.webp","structured_body":{"version":1,"layout":"flow","body_mode":"replace","rail_sections":[{"aside":{"type":"graphic","graphic":{"kind":"stat-board","title":"Routing rule","items":[{"label":"Vague work","value":"Frontier","detail":"Planning, exploration, broad synthesis"},{"label":"Bounded work","value":"Local AI","detail":"Private, repeated, checkable steps"},{"label":"Known work","value":"Script","detail":"Deterministic input and output"}]}},"blocks":[{"type":"markdown","content":"## The boundary is the architecture\n\nThe first mistake is expecting a small local model to behave like a frontier system with fewer parameters. Frontier models are useful because they are wide. They can absorb weak prompts, incomplete intent, and strange questions because their training and runtime infrastructure cover a large search space.\n\nLocal AI needs a narrower job. A laptop model is not useless because it fails at random general chat. It is being misused when it is asked to solve work that has no boundary. The real question is whether the task can be reduced to a defined sequence with controlled input, visible output, and review points.\n\nThat distinction matters for privacy and cost. Government work, NDA code, internal data, personal assistants, local voice tools, and sensitive workflows often cannot be pushed casually to hosted APIs. Privacy alone does not make the local model useful. Privacy plus a defined operating model is where the value appears."}]},{"aside":{"type":"graphic","graphic":{"kind":"bar-chart","title":"Where local AI fits","unit":"fit","series":[{"label":"Private repeated SOP","value":92,"note":"High fit"},{"label":"Fuzzy bounded input","value":78,"note":"Good fit"},{"label":"Open ended strategy","value":28,"note":"Frontier first"},{"label":"Deterministic transform","value":12,"note":"Script first"}]}},"blocks":[{"type":"markdown","content":"## SOPs make fuzzy work operable\n\nA standard operating procedure is not paperwork in this context. It is the interface between messy human material and a system that can do something repeatable. The workshop used the simple example of brushing teeth because even an ordinary action contains primitives: grab the brush, apply toothpaste, move through a sequence, finish with a known result.\n\nBusiness and software work can be decomposed the same way. Once the primitives are visible, model placement becomes less mystical. If a step has clean input and a predictable transformation, it should probably be a script. If the step receives natural language, partial context, ambiguous phrasing, rough notes, voice, images, or other fuzzy input, then an LLM can be useful.\n\nThe model should not own the whole process. It should own the fuzzy step that actually requires language or perception, then pass a bounded output into the next deterministic part of the workflow."}]},{"aside":{"type":"graphic","graphic":{"kind":"stat-board","title":"Local stack","items":[{"label":"Adapter","value":"Bias","detail":"Push the base model toward the task"},{"label":"Memory","value":"Ceiling","detail":"Fit the machine before chasing size"},{"label":"Harness","value":"Action","detail":"Tools, permissions, and review boundaries"}]}},"blocks":[{"type":"markdown","content":"## The model is only one part of the product\n\nA local model should be biased toward its task. That sentence sounds wrong only if the goal is a perfectly general assistant. For local AI, the useful outcome is usually the opposite: a model that knows the local domain, follows the local pattern, and behaves consistently inside a known workflow.\n\nLoRA-style adapters are useful because they keep the footprint small. A base model can remain compact while the adapter pushes it toward a specific style of code, a translation domain, a company process, or a tool-use pattern.\n\nThe hardware ceiling is real. A seven-billion-parameter model at full precision can occupy roughly fourteen gigabytes of memory before overhead. On a sixteen-gigabyte laptop, that leaves little room for the operating system, browser, and the rest of the working environment. Swap memory is not a strategy.\n\nChatting with a local model is the shallowest version of the idea. The useful question is what the model can do once it is connected to controlled tools. A harness gives the model access to files, search, commands, calendars, MCP servers, and local APIs. That is what turns a text box into a working system."}]}],"blocks":[]},"usage_policy_url":"https://www.martinatrin.com/ai-usage-policy","preferred_attribution_name":"Martin Atrin","preferred_attribution_text":"When citing, summarizing, or feeding this material into AI systems, attribute Martin Atrin and link the canonical source URL.","rights_summary":"Short quotations and summaries may be reused with clear attribution and a link to the canonical URL. Full-text republication, bulk scraping that impairs service, commercial redistribution, or training reuse beyond quotation requires permission.","copyright_holder":"Martin Atrin","in_language":"en","is_accessible_for_free":true,"published_at":"2026-05-05T00:00:00.000Z","updated_at":"2026-05-05 16:06:48"},{"id":"e85aedfe-dc7c-4985-812a-4ea337ad53e7","slug":"local-ai-workshop-short-notes","section":"notes","template":"editorial","title":"Short Notes From The Local AI Workshop","summary":"Short working notes from the Chiang Mai University workshop, compacted around model placement, SOPs, memory limits, and harness design.","body":"# Short Notes From The Local AI Workshop\n\nThese are compact notes from the February 2026 Chiang Mai University workshop on local AI and defined SOPs.\n\nThe useful split is not local versus cloud. It is vague versus bounded. Vague work belongs to frontier systems. Bounded work can belong to local systems. Deterministic work belongs to scripts. Useful action belongs inside a harness.\n\nThe memory and adapter details matter because they decide whether the system survives real use. Smaller, biased, quantized models with clear SOPs can be more useful than oversized local models that push a laptop into swap.\n\nThe final test is operational: can the model own one fuzzy step, produce a bounded output, and pass that output into the next part of the workflow without making everyone guess what happened.","author_name":"Martin Atrin","tags":["local-ai","sops","short-notes","chiang-mai-university","notes"],"canonical_url":"https://www.martinatrin.com/notes/local-ai-workshop-short-notes","image_url":"https://www.martinatrin.com/art/banners/notes-atrin.webp","structured_body":{"version":1,"layout":"flow","body_mode":"replace","rail_sections":[{"aside":{"type":"graphic","graphic":{"kind":"stat-board","title":"Placement note","items":[{"label":"Frontier","value":"Vague","detail":"Planning, open questions, broad synthesis"},{"label":"Local","value":"Bounded","detail":"Private, repeated, checkable steps"},{"label":"Script","value":"Known","detail":"Clean input and predictable transform"}]}},"blocks":[{"type":"markdown","content":"## The workshop frame\n\nThe most useful split from the session is not local versus cloud. It is vague versus bounded. When the question is still broad, exploratory, or poorly framed, a frontier model is the better instrument. It has the width to tolerate ambiguity. Local AI becomes useful after the work has been reduced into a narrower operating lane.\n\nThat lane is created by the SOP. A model should not be asked to own the whole workflow. It should own the fuzzy part: the natural-language request, the messy note, the uncertain input, the image or audio extraction, the summarization step, or the private coding context.\n\nThe core note is simple: the model is not magic glue. It is one component inside a workflow that has to be explicit enough to inspect."}]},{"aside":{"type":"graphic","graphic":{"kind":"bar-chart","title":"Design pressure","unit":"pressure","series":[{"label":"Memory fit","value":88,"note":"Avoid swap"},{"label":"Task bias","value":82,"note":"Use adapters"},{"label":"Tool boundary","value":74,"note":"Harness safely"},{"label":"Raw model size","value":38,"note":"Less important"}]}},"blocks":[{"type":"markdown","content":"## What changes when it runs locally\n\nLocal AI makes the privacy argument stronger, but it also makes the operating constraints more honest. A model that barely fits into memory is not practical just because it technically loads. If the operating system, browser, and tools have no headroom, the system will fall into swap and the experience will be slow enough to fail in daily use.\n\nThis is why smaller biased models matter. The target is not the biggest model a machine can technically run. The target is the smallest model that can do the bounded job with acceptable behavior. Adapters, post-training, and quantization are practical tools for that job because they move the model toward the task without forcing every workflow through an oversized base model.\n\nA chat box is not an operational system. A harness gives the model controlled access to files, search, commands, calendars, APIs, or MCP tools. That power only works if the model has clear permissions and narrow action boundaries."}]}],"blocks":[]},"usage_policy_url":"https://www.martinatrin.com/ai-usage-policy","preferred_attribution_name":"Martin Atrin","preferred_attribution_text":"When citing, summarizing, or feeding this material into AI systems, attribute Martin Atrin and link the canonical source URL.","rights_summary":"Short quotations and summaries may be reused with clear attribution and a link to the canonical URL. Full-text republication, bulk scraping that impairs service, commercial redistribution, or training reuse beyond quotation requires permission.","copyright_holder":"Martin Atrin","in_language":"en","is_accessible_for_free":true,"published_at":"2026-05-05T00:00:00.000Z","updated_at":"2026-05-05 16:06:48"},{"id":"4e802d04-9268-4862-9632-8d1516acec5d","slug":"weekly-ai-builder-notes-april-22-2026","section":"notes","template":"field-report","title":"Weekly AI Builder Notes: April 22, 2026","summary":"A compact note from the April 22 meetup deck: agent productivity stacks, self-hosting economics, local model tradeoffs, and weekly AI signals.","body":"# Weekly AI Builder Notes: April 22, 2026\n\nThis note points to the deck I used for the April 22 AI builder meetup. The source was a presentation slice set, so this article stays intentionally small and keeps the replayable deck attached.\n\nThe deck covered self-hosted productivity stacks for agents, Kimi K2.6, the GPT-6 watch, Claude Opus 4.7 and Claude Design, Qwen 3.6, RunPod economics, and a set of weekly AI stories. The useful connective tissue was ownership: what should run locally, what should run on a rented GPU, what should stay as an API call, and what should be organized as infrastructure rather than one more chat session.\n\nThe evergreen point is that builders need a mixed stack. Local small models, budget APIs, on-demand GPU sessions, and frontier systems are different instruments. The weekly briefing format helps keep those instruments from collapsing into one vague AI bucket.","author_name":"Martin Atrin","tags":["ai-weekly","meetup","deck-notes","agent-productivity","local-models"],"canonical_url":"https://www.martinatrin.com/notes/weekly-ai-builder-notes-april-22-2026","image_url":"https://www.martinatrin.com/art/banners/notes-atrin.webp","structured_body":{"version":1,"layout":"flow","body_mode":"replace","rail_sections":[{"aside":{"type":"media","media":{"kind":"deck","src":"/decks/weekly-apr22-2026.json","title":"AI Builder Weekly - April 22, 2026","caption":"Open the live deck to replay the April 22 meetup briefing, or open the JSON source from the attachment actions."},"title":"Replay deck","body":"The original meetup slides are attached as JSON and can be replayed in the presentation replay."},"blocks":[{"type":"markdown","content":"## The deck is the source\n\nThis was a meetup briefing built from presentation slices. The article should not pretend to be a transcript. The useful object is the deck, with a short note explaining why the sequence mattered.\n\nThe April 22 session moved from agent productivity stacks into model and infrastructure choices. Self-hosting, Kimi, Claude, Qwen, RunPod, and weekly AI news were all ways of circling the same practical question: what does a builder need to own directly, and what can be rented or called as a service?\n\nThat frame is more durable than the individual release notes. The exact model names will keep changing. The placement problem stays."}]},{"aside":{"type":"graphic","graphic":{"kind":"stat-board","title":"Deck shape","items":[{"label":"Slides","value":"17","detail":"Weekly briefing format"},{"label":"Main pressure","value":"Ownership","detail":"Local, hosted, rented, or API"},{"label":"Useful lens","value":"Mixed stack","detail":"Use the right instrument for the job"}]}},"blocks":[{"type":"markdown","content":"## What carried forward\n\nThe practical takeaway was a mixed-stack mindset. A local model can answer small private questions. A budget API can cover medium tasks. A rented GPU can handle focused heavy sessions. A frontier model still earns its place when the work needs judgement, long context, or high quality synthesis.\n\nThe problem is not choosing one permanent winner. The problem is knowing what the work needs before the tool choice becomes habit.\n\nThe replay is attached because the deck shows the transitions between those choices. It is more useful as a working sequence than as a list of isolated headlines."}]}],"blocks":[]},"usage_policy_url":"https://www.martinatrin.com/ai-usage-policy","preferred_attribution_name":"Martin Atrin","preferred_attribution_text":"When citing, summarizing, or feeding this material into AI systems, attribute Martin Atrin and link the canonical source URL.","rights_summary":"Short quotations and summaries may be reused with clear attribution and a link to the canonical URL. Full-text republication, bulk scraping that impairs service, commercial redistribution, or training reuse beyond quotation requires permission.","copyright_holder":"Martin Atrin","in_language":"en","is_accessible_for_free":true,"published_at":"2026-05-05T00:00:00.000Z","updated_at":"2026-05-05 16:06:48"},{"id":"d1793dfd-c43b-436f-8a99-e8db5ab5924b","slug":"weekly-ai-builder-notes-april-29-2026","section":"notes","template":"field-report","title":"Weekly AI Builder Notes: April 29, 2026","summary":"A compact note from the April 29 meetup deck: model releases, pricing pressure, cloud distribution shifts, and practical builder tools.","body":"# Weekly AI Builder Notes: April 29, 2026\n\nThis note points to the deck I used for the April 29 AI builder meetup. It was a weekly briefing rather than a transcript, so the useful artifact is the replayable slide sequence and a compact record of what the room was meant to carry forward.\n\nThe deck moved through GPT-5.5, DeepSeek V4, Microsoft and OpenAI distribution changes, the Musk v. Altman trial, budget coding options, and a small OSS tool roundup. The practical thread was pricing pressure and model placement: builders should know when to pay for frontier quality, when to use cheaper open endpoints, and when the toolchain matters more than the model headline.\n\nThe evergreen point is that AI infrastructure is becoming a routing problem. Capability, price, latency, privacy, and workflow ownership all matter. The weekly format is useful because it keeps those variables visible before they harden into habit.","author_name":"Martin Atrin","tags":["ai-weekly","meetup","deck-notes","open-models","builder-briefing"],"canonical_url":"https://www.martinatrin.com/notes/weekly-ai-builder-notes-april-29-2026","image_url":"https://www.martinatrin.com/art/banners/notes-atrin.webp","structured_body":{"version":1,"layout":"flow","body_mode":"replace","rail_sections":[{"aside":{"type":"media","media":{"kind":"deck","src":"/decks/weekly-apr29-2026.json","title":"Know Enough AI to be Dangerous - April 29, 2026","caption":"Open the live deck to replay the April 29 meetup briefing, or open the JSON source from the attachment actions."},"title":"Replay deck","body":"The original meetup slides are attached as JSON and can be replayed in the presentation replay."},"blocks":[{"type":"markdown","content":"## The deck is the source\n\nThis was a meetup briefing, not a transcript. The deck is therefore the primary source: a sequence of slices designed to move quickly through the week without pretending every headline deserves a full essay.\n\nThe April 29 session centered on model release pressure, model pricing, and distribution changes. GPT-5.5, DeepSeek V4, Microsoft and OpenAI, budget coding subscriptions, and OSS builder tools were all part of the same practical question: what should a builder actually use next week?\n\nThat question matters more than the headline race. For a working team, the right answer depends on price, speed, data sensitivity, available tooling, and whether the task needs frontier judgement or a cheap reliable lane."}]},{"aside":{"type":"graphic","graphic":{"kind":"stat-board","title":"Deck shape","items":[{"label":"Slides","value":"14","detail":"Weekly briefing format"},{"label":"Main pressure","value":"Price","detail":"Cheaper open endpoints versus frontier quality"},{"label":"Useful lens","value":"Routing","detail":"Pick model, provider, and workflow together"}]}},"blocks":[{"type":"markdown","content":"## What carried forward\n\nThe useful thread was not that one model won the week. The useful thread was that model choice is becoming more operational. DeepSeek V4 made the price discussion sharper. GPT-5.5 kept the frontier race moving. The Microsoft and OpenAI shift made cloud distribution less locked to one lane.\n\nFor builders, that means the default question should be more specific. Is this a quality problem, a cost problem, a speed problem, a privacy problem, or a workflow problem? Each answer points to a different stack.\n\nThe replay is attached because the value is in the sequence. It shows the way the topics relate, not only the individual facts."}]}],"blocks":[]},"usage_policy_url":"https://www.martinatrin.com/ai-usage-policy","preferred_attribution_name":"Martin Atrin","preferred_attribution_text":"When citing, summarizing, or feeding this material into AI systems, attribute Martin Atrin and link the canonical source URL.","rights_summary":"Short quotations and summaries may be reused with clear attribution and a link to the canonical URL. Full-text republication, bulk scraping that impairs service, commercial redistribution, or training reuse beyond quotation requires permission.","copyright_holder":"Martin Atrin","in_language":"en","is_accessible_for_free":true,"published_at":"2026-05-05T00:00:00.000Z","updated_at":"2026-05-05 16:06:48"}]}