标签：#ai

The plan was simple Take the specs we'd written, turn them into Jira epics, stories and subtasks, and start sprinting. It took longer than expected. Here's what actually happened — and what I learned. Why automate Jira setup at all? HandyFEM has 8 epics, 37 stories and ~160 subtasks. Creating that manually would take a full day and be error-prone. More importantly: the specs were already written in a structured format. Translating structured data into Jira issues is exactly the kind of repetitive task that should be automated. So I wrote a Node.js script to do it via the Jira REST API. Problem 1 — Jira Spaces ≠ Jira Classic My account uses Jira Spaces — Atlassian's newer interface. The classic Jira has CSV import built in. Jira Spaces doesn't. This isn't documented anywhere obviously. You discover it by looking for the import option and not finding it. Lesson: always check which version of Jira you have before planning your workflow. The API still works, but some endpoints behave differently. Problem 2 — The API token wasn't the issue (until it was) First attempt: connection error. I assumed it was the token. It wasn't — it was an expired token from a previous session. Regenerating it fixed the connection. The real lesson: curl -u email:token https://your-domain.atlassian.net/rest/api/3/myself is the fastest way to verify auth before running any script. Problem 3 — customfield_10014 doesn't exist in team-managed projects In classic Jira, linking a story to an epic uses a field called customfield_10014 (Epic Link). In team-managed projects (Jira Spaces), this field doesn't exist. You use parent instead. The error was clear once I saw it: "customfield_10014" : "Field cannot be set. It is not on the appropriate screen, or unknown." Fix: remove customfield_10014 , keep only parent: { id: epicId } . Problem 4 — Board search doesn't work for team-managed projects The Agile API endpoint /rest/agile/1.0/board?projectKeyOrId=HFM returns empty for team-managed projects, even

Notes on Federated Learning and Differential Privacy 2026-05-31 · privacy-preserving ML Working notes on building federated learning (FL) from scratch, what actually breaks under Non-IID data, and how differential privacy (DP) and secure aggregation fit on top — including the honest negative results that the marketing slides leave out. They follow the implementation in federated-learning-lab (FedAvg / FedProx / SCAFFOLD, DP-SGD, secure aggregation; 33/33 tests, literature cross-validated). 1. What federated learning actually is The data never moves. Instead of pooling everyone's data on one server, each client trains locally and sends model updates to a server that aggregates them. The canonical loop ( FedAvg ) is: Server broadcasts the global model. Each client does a few local SGD epochs on its own data. Each client sends back its updated weights. Server averages the weights (weighted by client data size) → new global model. That's it. The elegance is that raw data stays on-device; the difficulty is that the clients' data distributions are not identical. 2. The Non-IID problem (where FedAvg starts to hurt) FedAvg implicitly assumes every client sees roughly the same distribution. Real clients don't — one hospital sees different cases than another, one phone's keyboard sees different language. Under Non-IID data, each client's local optimum pulls in a different direction, so averaging their updates produces client drift : the global model lands somewhere none of them wanted. Two well-known fixes, both implemented and measured in the lab: FedProx — add a proximal term that penalises drifting too far from the global model. Stabilises training when clients are heterogeneous. SCAFFOLD — track control variates (correction terms) that estimate and subtract the drift direction. More state to communicate, but corrects the bias FedProx only damps. The honest finding worth repeating: on a strongly Non-IID split (e.g. label-skewed MNIST), the fancy methods don't always beat p

0 % vs 50 %: making a RAG agent refuse to hallucinate 2026-05-31 · LLM / RAG A retrieval-augmented agent is only as trustworthy as its behaviour on questions whose answer isn't in the corpus . The failure mode is quiet: instead of saying "I don't know," the model invents a confident, well-formed, wrong answer. This post shows a single guardrail that takes that from common to never — and, crucially, measures it. Reference architecture: nim-agent-blueprint — agentic RAG on the NVIDIA NIM stack with a built-in eval harness. The ablation The agent loop is plan → retrieve → generate → validate . The interesting variable is the generation prompt's contract with the retrieved context: Configuration Out-of-corpus hallucination rate Generate freely from context ~50 % Guarded prompt (answer only from context; otherwise abstain) 0 % Same model, same retriever, same questions. The only change is a prompt that makes "I can't answer that from the provided sources" a first-class, rewarded output — plus a validate step that checks the answer is grounded in retrieved spans before returning it. On in-corpus questions, retrieval recall@3 stayed at 94–100 % , so the guardrail buys safety without costing coverage. Why "just prompt better" isn't the lesson The lesson isn't the prompt — it's that the difference between 50 % and 0 % is invisible without an eval harness . A demo that only asks in-corpus questions looks perfect in both configurations. You only see the 50 % when you deliberately ask things the corpus can't answer and score groundedness . So the blueprint ships with: retrieval hit-rate (is the answer even retrievable?), answer groundedness via LLM-as-judge (is the answer supported by what was retrieved?), latency , and OpenTelemetry traces per agent step. That's the difference between "it works on my five questions" and "here is the number a partner can hold me to." Takeaway For enterprise RAG, abstention is a feature, not a failure. Make "I don't know" a rewarded output, vali

Earlier this month, I finally achieved the elusive goal I had set for myself in Bungie's Marathon. I collected six of the game's rarest items, allowing me to attempt and then successfully clear the raid-style Compiler boss. I felt a massive weight lift off my shoulders - nearly 185 hours of playtime and I had […]

The crypto weed vape found me on 4/20, the high holiday of cannabis enthusiasts everywhere. It arrived over Slack with the thumbnail of a man exhaling a plume of vapor, the words "every hit delivers Bitcoin" emblazoned across it. It claimed to be advertising a device called Gudtrip, and I thought everything about it sounded […]

I’ve spent a lot of time lately thinking about why some LLM agents feel "intelligent" while others just feel like chatbots with a slightly better prompt. It almost always comes down to how the system handles memory. When we treat the context window as the only place for state, we hit a ceiling very quickly. To build an actual agent, we have to move away from "one big prompt" and toward a layered memory architecture. Agentic Memory can be categorized in 4 layers by their function: Working Memory: The current context window. It's our RAM—fast, essential, but wiped clean after every session. Semantic Memory: The Vector DB or knowledge base. This is where the "world rules" and global conventions live. It’s the reference manual the agent checks to stay aligned. Procedural Memory: The "how-to" layer. Instead of stuffing every tool description into the prompt, the agent maintains a lean index of skills and pulls in the full implementation only when a specific task triggers it. This keeps the context window clean. Episodic Memory: This is the hardest part. It's the ability to distill a past interaction into a reusable insight. The real engineering challenge here isn't storage—it's the "forgetting" logic. Deciding what is noise and what is a core pattern is where most frameworks still struggle. Depending on the use case, the architecture changes: Reflex Agents: Just Working Memory. Support Agents: Working + Procedural. Coding Agents: The full stack. The gap between a demo and a production-ready agent is usually the distance between simple RAG and a functioning episodic memory. The ability to compress experience into a usable state is still a significant hurdle. Which of these layers are you currently implementing, and how are you handling the "forgetting" logic in your episodic memory?

Now that almost everyone has thought about or is actively integrating AI workflows into their projects, some might ask is this all worth the cost? Many think the current economics of the AI space don't scale and that there will be upward price movement. Others still might not be comfortable with sending their data to remote services for processing. Then there is the crowd that wants to deploy models in small spaces with limited compute. Are there ways we can deploy small models locally and run at a lower cost? Yes with Knowledge Distillation . Knowledge distillation can get a bad rap due to it's questionable use in training some Large Language Models (LLMs). But it's a perfectly valid way to transfer performance from a larger model to a smaller one. Especially when both models are yours and/or open. This article will explore progressive distillation which is a technique to incrementally transfer knowledge from a series of larger teacher models into a smaller student. Install dependencies Install txtai and all dependencies. pip install txtai [ pipeline - train ] datasets Setup the Training Pipeline The first step we need to do is setup up the training pipeline. We'll use the Hugging Face Training framework to build a series of models. The following code establishes a train method, test method and loads the classification training data. from datasets import load_dataset from transformers import AutoModelForSequenceClassification , AutoTokenizer from txtai.pipeline import HFTrainer , Labels def train ( teacher , student , distillation , ** kwargs ): trainer = HFTrainer () model = AutoModelForSequenceClassification . from_pretrained ( student , trust_remote_code = True ) tokenizer = AutoTokenizer . from_pretrained ( student , trust_remote_code = True ) return trainer ( ( model , tokenizer ), ds [ " train " ], columns = ( " sentence " , " label " ), maxlength = maxlength , teacher = teacher , distillation = distillation , ** kwargs ) def test ( model ): labels = Labels (

"A language model that answers questions is a tool. A language model that decides which questions to ask and then acts on the answers is something else entirely." Introduction: When Models Started Deciding For the first several years of modern NLP, the task was always the same: given input, produce output. One forward pass. One completion. Done. In 2022, a paper from Google Brain asked a different question. What if, instead of producing an answer directly, a model could reason about what information it needs, act to retrieve it, and revise its thinking based on what it found? The paper was ReAct: Synergizing Reasoning and Acting in Language Models (Yao et al., 2022). Applying it to an LLM created something qualitatively different: a model that could take real-world actions and adapt its reasoning based on what came back. A completion model is a calculator. An agent is a process: it has a goal, takes steps toward it, and updates when things go wrong. This week I went deep on the architecture behind these systems, the frameworks that define them, and what the open problems look like from a research perspective. Part 1: What Makes a System "Agentic"? The word "agent" gets used loosely in current literature. A clean definition comes from Russell and Norvig's Artificial Intelligence: A Modern Approach : An agent is anything that perceives its environment through sensors and acts upon that environment through actuators. For an LLM-based system, this is a loop: perceive an observation, reason about what to do, act via a tool call or output, observe the result, and loop again. But not every loop qualifies as agentic. Three properties distinguish genuinely agentic systems from tool-augmented chatbots: Property What It Means Goal persistence Maintains the original goal across multiple steps without re-prompting Adaptive planning Revises its approach based on intermediate results Tool autonomy Decides when and which tools to use, not just how to use one it was told to call Mos

Claude Code added Dynamic Workflows. Dynamic Workflows are a way to run larger coding tasks as a...

Stacking, Bidirectionality, the Encoder-Decoder, and LSTMs Last post ended with a simple RNN and three promises: LSTMs, bidirectional RNNs, and attention. This post delivers the first two, plus the refinements that turn a working-on-paper RNN into something you'd actually deploy. By the end, you'll know how to stack RNNs for depth, why reading a sentence backward as well as forward (bidirectionality) makes representations sharper, how the encoder-decoder turns one sequence into a different one for machine translation, and exactly what breaks in a simple RNN that LSTMs and GRUs were invented to fix. Attention, the fix for the last problem we'll hit, gets its own home in the transformer post, so we'll stop right at the edge of it. The simple RNN was the idea. This post is the engineering. A vanilla RNN carries a thread of hidden state through time, but in practice, that thread frays on long sequences, only sees the past, and bottlenecks everything through one final vector. Each section here is a fix for one of those problems. Put them together, and the path from "RNN" to "transformer" looks less like a leap and more like a series of obvious next steps. Stacking RNNs for Depth The first refinement is the easy one. Nothing says an RNN's output has to go straight to a prediction. You can feed the entire output sequence of one RNN as the input sequence to another. Then another. These are stacked RNNs (also called deep RNNs), and they usually outperform a single layer. Why does depth help? The same reason it helps in vision. Each layer learns representations at a different level of abstraction. The lower layers pick up fundamental, local properties; in language, that's roughly the level of parts of speech and named entities. The higher layers compose those into bigger groupings: descriptive phrases, "this is the answer to a question," and so on. We can't point at layer 3 and say "this one does coreference." But the theory holds up well enough that researchers have probed m

The Question Nobody Wants to Ask: Does Your Skill Actually Help? You spent an afternoon crafting a carefully structured Skill for your agent. Clear steps, thorough edge-case notes, well-formatted output requirements. You tested it manually a few times, the outputs looked great. You shipped it. Three weeks later, you notice that some task success rates have gone down compared to before the Skill existed. This is not a hypothetical. In May 2026, Microsoft Research published two concurrent papers — SkillLens ("From Raw Experience to Skill Consumption") and SkillOpt ("Executive Strategy for Self-Evolving Agent Skills") — that measured this failure mode at scale. Their finding: negative transfer happens in 25% of cases , and you cannot reliably identify the bad skills just by reading the text. One paper answers "why skills sometimes backfire." The other answers "how to make skills systematically better." Together they sketch a new paradigm for agent capability improvement. Part One: SkillLens — Mapping the Full Skill Lifecycle A Skill Is Not a Point — It's a Pipeline Most practitioners think of a Skill as "a block of text instructions for an agent." SkillLens decomposes this into a three-stage lifecycle : Stage 1: Experience Generation Target model M runs training tasks, producing an experience pool of trajectories (both successes and failures) ↓ Stage 2: Skill Extraction Extractor model E distills the experience pool into a structured skill document — procedural knowledge under a fixed budget ↓ Stage 3: Skill Consumption The same target model M, equipped with the extracted skill, is evaluated on held-out test tasks Notice there are two distinct roles in this chain: the Extractor (distills knowledge from trajectories) and the Target (consumes knowledge to improve task performance). SkillLens's central insight is that these two roles are independent — a strong task executor is not necessarily a strong extractor, and vice versa . Two New Metrics: EE and TE To separate thes

I used to deploy Node.js apps on EC2 and manage servers like it was my second job. Port configs. PM2 restarts. Nginx rewrites. SSL renewals. Then I ran my first AWS Lambda function. 80% of that work is gone. Here's what Lambda actually does that nobody explains clearly: → You write a function → AWS runs it ONLY when triggered → You pay for milliseconds of execution → It scales from 1 to 1,000,000 requests without you touching anything As a full-stack developer in Bahrain, preparing for my AWS Developer Associate exam, this is the shift that changes how you think about backend architecture. Not "how do I manage a server" but "what should happen when this event fires." That mental model switch took me a week to fully get. I'm documenting everything as I study. Drop a 🔥 if you want me to share my Lambda notes weekly.

By Takeshi Yokoyama — Onecarat Labs Hi. I'm Yokoyama, and I build a local-first AI text editor as a side project, along with a few other experimental tools. Working on them, I keep running into the same question about where the web is going. This post is one observation, plus a small experiment I built to test it — including a Chrome extension you can actually try. The short version: I think websites will increasingly be read through AI agents, reshaped per reader, on the fly. And once that happens, there's a clear gap between sites that are easy for an AI to read and sites that aren't. What's starting to happen Until now, people read websites as websites. You open the top page, follow the menu, read the body, click a button — tracing the path the maker designed. As local AI and AI agents become normal, that breaks. People stop opening the page directly. They tell an AI what they want — "Can I try this quickly?" , "I just want to check it's safe" , "Just the gist" — and the AI reads the web and reshapes it into the form that reader wants. What the reader receives is no longer the layout the maker built. This isn't speculation. The idea that AI generates the interface for the reader already has a name — Generative UI — and it's one of the hottest areas in frontend right now, with Google, Vercel and others building toward it. But notice who's holding the pen in almost every version of that story: the site , or an AI embedded in an app — something under the maker's control. What I'm looking at is one step past that: a local AI, in the reader's own hands, reshaping any site into that person's preferred form — with no involvement from the maker at all. The initiative moves from the maker to the reader. The part that nags at me as a builder I build software too. So this shift nags at me. A site carries its maker's intent and rights. The order things appear in, what gets emphasized, the tone. Design, copy, flow — all of it is deliberate. Having an AI quietly reorder, rewri

In the past, when people heard the word “token,” they usually thought about cryptocurrency, trading,...

Agent Memory: Short-Term, Long-Term, and Episodic Main Thumbnail Image Prompt: A human brain cross-section illustration in neon tones on dark background. Three regions clearly demarcated and labeled. The hippocampus region glows blue, labeled "Episodic Memory: what happened." The prefrontal cortex glows orange, labeled "Working Memory: what I'm doing now." A network of distributed nodes glows green, labeled "Semantic Memory: what I know." Arrows show information flowing between regions. Scientific but accessible, the memory architecture made neural and visual. Memory Architecture Diagram Image Prompt: Four storage boxes arranged vertically on dark background. Top: "In-Context Window (Working Memory)" — fastest, smallest, temporary, shown as RAM chip icon. Second: "External Vector Store (Semantic Memory)" — fast retrieval, persistent, shown as cylinder with search icon. Third: "Key-Value Store (Episodic Memory)" — structured facts, shown as database icon. Bottom: "Fine-Tuned Weights (Procedural Memory)" — slowest to update, most permanent, shown as brain with lock. Arrows showing read/write speeds between boxes. Clean, technical, the hierarchy is the insight. Memory Retrieval Flow Image Prompt: A query arrives at an agent on the left. Four parallel arrows go right to four memory sources: conversation history (short chat bubbles), vector database (semantic search visualization), structured database (table icon), model weights (brain icon). Each source returns relevant items. A "Memory Fusion" box on the right combines the results. The agent sees an enriched context. The retrieval from multiple stores is the architecture. Every conversation with an LLM starts from zero. You explain your project. You explain your preferences. You explain your constraints. You spend five minutes providing context. You come back tomorrow. You do it all again. The model remembers nothing between sessions. The context window closes. The state is gone. Every interaction is the agent's first

174 million smart TVs, most of which run Linux. 3.9 billion Android phones. Zero marketing. Tonight, somewhere around the world, a person will press the power button on their Samsung TV. A proprietary Samsung logo will appear. A polished menu will load. They will open Netflix, scroll through recommendations, and pick a movie. They will never know that every frame they see is being scheduled, managed, and rendered by a Linux kernel, the invisible engine that sits between apps and hardware. They will then reach for their Android phone to check something on social media. Another Linux kernel. If they are sitting in a Tesla, the touchscreen showing their charging status is running yet another Linux kernel. The “year of the Linux desktop” debate has been running for two decades. Entire forums exist to argue about whether 2025, 2026, or 2027 will finally be the year Linux takes over the PC market.

You've seen this before. You ask your AI agent: "Find ∫ x·e^x dx" It confidently replies: e^x + C , complete with a plausible-looking derivation. You nod. Then you check — the correct answer is (x−1)·e^x + C . It was wrong by a mile, and you almost shipped it. This is the fundamental problem with AI math today: LLMs can talk, but they can't verify their own work. They sound convincing while being catastrophically wrong. And the more complex the problem, the better the hallucination. Math.skill changes that. It's an open-source mathematical reasoning skill for AI agents — install it, and your agent stops guessing and starts verifying. What Makes It Different Typical AI Math Plugin Math.skill Workflow Prompt → LLM → answer Prompt → 7-step pipeline → ≥2 verifications → answer Verification None Answer blocked if verification fails Open problems Might hallucinate a "solution" Honestly says "this is unsolved" Error recovery No mechanism Auto-backtrack, fix, recompute, re-verify The core differentiator: a verification engine that runs at least 2 of 11 independent checks on every answer. No answer leaves the pipeline unverified. Period. The 7-Step Pipeline Every problem flows through this: Step What Happens Why It Matters 1. Parse Extract conditions, goals, variables, implicit domain constraints Catches misread problems before they waste your time 2. Model Build formal representation: equation, function, matrix, probability space, etc. Prevents building the wrong mathematical structure 3. Select Choose the optimal method from 30+ strategies Avoids brute-forcing when elegance exists 4. Solve Step-by-step with mathematical justification at every transformation Full traceability — nothing hidden 5. Verify Apply ≥2 of 11 independent verification methods The differentiator — catches what LLMs miss 6. Correct If verification fails: backtrack to last known-good step, fix, recompute, re-verify No "doubling down" on wrong answers 7. Deliver Exact answer (not approximate), domain con

AI applications are moving quickly from simple chatbots to systems that can search, reason, recommend, summarize, and act on live business data. For developers, that usually means wiring together databases, embedding models, vector search, rerankers, orchestration logic, and application code. For no-code AI builders, it often means waiting for those integrations to exist before an idea can become a working prototype. The MongoDB extensions for Dify help close that gap. With the new MongoDB Atlas and Voyage AI extensions, Dify builders can visually compose AI workflows and agents that connect directly to MongoDB data, perform semantic retrieval with Atlas Vector Search, improve result quality with Voyage AI embeddings and reranking, and optionally interact with operational documents through controlled database tools. The result is a practical path from idea to working AI application: less custom orchestration code, more reusable building blocks, and a smoother experience for both developers and no-code builders. Why Dify and MongoDB Belong Together Dify provides a visual environment for building AI apps, workflows, and agents. It makes it easy to connect user input, model calls, tools, prompts, and outputs into a working application. MongoDB Atlas provides the data foundation: flexible documents, operational queries, aggregation, full-text search, and vector search in one platform. Together, they create a powerful pattern: Dify orchestrates the AI experience — workflows, agents, prompts, tools, and user interactions. MongoDB Atlas stores and retrieves the data — documents, application records, knowledge sources, and vector embeddings. Voyage AI improves retrieval quality — embeddings for semantic search and reranking for precision. For a no-code builder, this means you can assemble a retrieval-augmented generation workflow visually. For a developer, it means the integration points are packaged as reusable Dify tools rather than one-off glue code. Meet the Extensions

Intel Foundry's Rio Rancho Facility Moves Toward Glass Substrate Volume Production Reports from Wccftech and Forbes (May 26, 2026) indicate that Intel Foundry's facility in Rio Rancho, New Mexico, is advancing toward becoming the world's first factory to achieve mass production of glass substrates — a next-generation chip packaging technology considered critical for scaling AI hardware beyond current organic substrate limitations. The facility has already begun manufacturing silicon photonics products for external customers and is expected to play a central role in Intel's advanced packaging strategy. Why Glass Substrates Matter for AI Glass substrates address fundamental limitations of current organic (ABF) substrates that are becoming bottlenecks for AI chip scaling: Extreme flatness (<1 μm warpage) enables larger die and chiplet assemblies Low CTE (3-8 ppm/°C) closely matches silicon (2.6 ppm/°C), reducing thermal stress Higher interconnect density due to dimensional stability Better high-frequency performance with low dielectric loss Larger format supporting bigger interposers than organic substrates For AI accelerators that already push CoWoS substrate limits at 5,500+ mm², glass substrates could enable even larger multi-chiplet assemblies. Intel's Advanced Packaging Ecosystem Intel has been building an advanced packaging portfolio: EMIB (Embedded Multi-die Interconnect Bridge): High-density die-to-die connections Foveros : 3D stacking for logic-on-logic packaging Co-Packaged Optics (CPO) : Recently demonstrated glass-core substrate prototypes with CPO Customer Base According to Forbes: Existing customers : AWS, Cisco Reportedly in discussion : Apple, Google, Microsoft, Nvidia, Tesla Commercial Timeline Milestone Timeline Glass substrate R&D announcement 2023 Pilot line (Chandler, AZ) 2024-2025 Silicon photonics production (Rio Rancho) 2026 (active) Glass substrate volume production ~2028-2030 Global Competition Intensifying SKC/Absolics (Korea): Operating pilo

You’re Overpaying Every Day — You Just Can’t See It Think about the last time you asked an AI to clean up your meeting notes. You probably opened a new chat, pasted in the transcript — maybe 1,500 words — then pasted your usual notes template on top of that, then said something like “format this, bold the action items.” It worked. Useful, even. But here’s what actually happened: the model just read ~3,000 words to produce ~300 words of output. Do that five times a week. Every week. And now think about what’s riding along in that context every single time — your template, your formatting preferences, all the background you’ve already explained before. The model doesn’t remember any of it. It reads it fresh on every call. Every repeat. Every charge. This isn’t a flaw in ChatGPT. It’s the fundamental nature of chat as a paradigm. 2. Chat Is Great — But It Has a Structural Bug Chat is the most natural way to start with AI. Unclear what you want? Talk it out. Need to change direction? Just say so. The feedback loop is instant, the barrier is zero. That’s why everyone starts there. But chat has a structural problem: every single turn carries the entire history. This is how context windows work — the “conversation history the model reads every single time.” Every API call packages up your full history and sends it to the model. You pay for every token the model reads. Ten rounds in, round ten doesn’t cost the price of one message. It costs the price of all ten, stacked. Here’s a concrete version of this. Say you use AI to write your weekly status update. You paste in your bullet points from the week, say “turn this into a proper update,” tweak the tone, go back and forth a couple times. Feels efficient. But those bullets, plus the AI’s draft, plus your follow-up messages, plus the format you’re implicitly re-explaining each time — the real token cost of one weekly update is probably 5 to 8x what you’d guess. You’re paying for repeated context. The bill just isn’t obvious e