The PC industry has never been shy about creating labels. Multimedia PC. Internet PC. Ultrabook. Creator laptop. Gaming rig. Workstation. Some of those labels described real shifts in architecture or use. Others mostly offered marketing teams a new sticker for […]
The post AI PCs Need Better Labels Than AI PC appeared first on TechSpective.
Claire chatted to Maria Koskinopoulou from Heriot-Watt University about autonomous robotic manipulators for surgery, industry, and beyond.
Maria Koskinopoulou is an Assistant Professor in Robotics and Computer Vision at Heriot-Watt University. She co-leads the ARM²Lab – Autonomous Robotic Manipulation & Multi-Agent Systems Lab at Heriot-Watt and the National Robotarium, alongside Ignacio Carlucho. Her research interests include robotic manipulation, perception, robot vision, medical robotics, human-robot interaction, and machine learning. She is involved in major UKRI and EU-funded research projects advancing robotic manipulation, surgical and underwater robotics, autonomous assembly, and waste sorting.
The third post from Build Club, our weekly live build session. The companion GitHub repo can be found here, docs here and you can try the agent live in the hosted playground.
Your agent framework is not the bottleneck. The bottleneck is that every new external system your agent needs to talk to requires another tool wrapper, another MCP server, another item in a registry that is always two steps behind the API it wraps.
The conventional model is “agent plus curated tool registry.” It scales linearly with the number of integrations your agent has to do, and the curation is permanent work. You ship a wrapper. The vendor changes their endpoint. The wrapper drifts. The agent gets stuck. You ship another wrapper.
There is a pattern emerging in production that inverts this approach. The new model is “agent plus secure sandbox plus raw API specs.” The tools are not pre-built. The agent writes them on the fly, using the spec as its only reference, runs them in a boundary you trust, and discards the ones that turn out to be wrong. The framework’s job is not to provide tools. The framework’s job is to make tool-authoring safe.
Luke Shulman, Director of Agent Innovation at DataRobot, walked through this pattern in a recent Build Club session.
The audience picked the problem: CODEOWNERS hygiene in the DataRobot monorepo. Every monorepo of meaningful age accumulates this kind of drift as teams reorganize, get renamed, or get absorbed. Files end up annotated with aliases that no longer point anywhere. The cleanup is mechanical, tedious, and a good first target for an agent. A member of the platform team surfaced it as the build target: scan the repo, find files owned by teams that no longer exist, propose reassignments, open the PR.
Luke built it live, in an hour, on a modest 35B-parameter model. He did not pre-build a single tool. The agent wrote them.
This post is the recipe.
Luke’s NL agent authoring its first tool against the GitHub OpenAPI spec.
Luke calls this pattern a Natural language (NL) agent, also referred to as a context-agent.
The framing matters because it inverts where your engineering effort goes. In the conventional setup, you spend your time on the tool registry. In an NL agent, you spend your time on the sandbox.
The agent runs in a Deno-based JavaScript VM with a restricted directory, a restricted network allowlist, and a restricted set of environment variables. JavaScript is the right execution surface for this because the entire browser ecosystem is built on running untrusted JavaScript safely. Deno tightens that further with explicit permissions for file, network, and environment access.
The agent gets eight tools to start: cat, find, grep, tree, write, search-and-replace, mkdir, and execute_code. Everything else, the agent has to author itself. The execute_code tool is the unlock. The agent reads a markdown system prompt, reads any reference docs in its directory, and starts writing JavaScript functions to talk to the external system. It tries them. It fixes them when they fail. The functions it keeps get saved as a tools.js file in the working directory. The next time the agent loads, those tools are already there.
The asymmetry is favorable. Setup is short. The infrastructure is small. The agent does the integration work itself against a spec that is, by definition, more complete than any wrapper anyone was going to maintain. You do not have to be ahead of the agent’s needs. The spec already is.
Everything below assumes you have the NL agent runtime (open-sourced at github.com/kindofluke/context-agent) and a DataRobot account. If you would rather see the pattern before you build, the hosted playground runs the agent live in your browser against a sample knowledge base.
Create a fresh working directory. This is the only place the agent can read or write. Configure the Deno sandbox to allow only .js and .md file types within that directory. Configure the network allowlist to permit only the domains you want the agent to hit. For this build, that meant api.github.com and nothing else.
This is the load-bearing step. If you give an agent the ability to write code without a safe place to run it, you get either a refusal-prone agent or a security incident. The framework’s value is the sandbox, not the agent loop.
Download the GitHub OpenAPI spec and put it in the agent’s directory as github-openapi.yaml. Do not write a wrapper. Do not pre-author tools. The spec is all the context the agent needs.
Overview of the agent’s directory and context during the build.
This is the move that gets the most pushback and is the most important. The conventional instinct is to write a thin client around the API and hand the agent the client. The NL pattern is to hand the agent the spec and let it write its own thin client, only for the endpoints it actually ends up needing. Most wrappers cover surface area that never gets used.
Generate a GitHub fine-grained personal access token scoped to Contents: read and Pull requests: write for the target repo. Minimum required scope, nothing more.
The NL runtime exposes environment variables to the agent only when they carry a specific prefix (NL_ in Luke’s setup). Anything without the prefix is invisible to the agent. This is how you stop it from accidentally reading credentials it has no business reading. Set NL_GITHUB_TOKEN=<your_pat> and the agent will pick it up. Anything else in your shell stays out of reach.
In the chat interface, tell the agent what it has access to and ask it to confirm connectivity. The first thing it will do is author a probe tool, five or ten lines of JavaScript that hits the rate-limit endpoint. When that works, give it the real task: “find every file in the monorepo owned by @datarobot/cloud-operations in the DR_CODEOWNERS file.”
The agent’s first move was to author a tool it named getCodeownersFiles. About twenty lines. It walked the repo via the GitHub API, parsed CODEOWNERS patterns, and returned a list.
It ran the tool, got back the list, and then, without being asked, wrote a second tool to persist the list as a cloud-ops-inventory.txt file in its directory. The agent figured out on its own that a file makes a perfectly good working memory. The tools-as-emergent-memory pattern fell out of the runtime without anyone designing for it.
The agent’s default behavior is to do too much. Before you let it propose changes to the repo, give it a system prompt that draws a hard line around what it can modify:
The CODEOWNERS guidelines only update CODEOWNERS references. Do not modify real running code. Only open PRs. Be safe.
That sentence stops the agent from “helpfully” refactoring code while it is in the file. Scope discipline matters more than capability when you are handing an agent write access to a production repo. From there, the agent worked through the inventory file by file, proposing reassignments where the git history made the new owner obvious and flagging the rest for human review. The PR-creation step stayed in the loop with a human reviewer, which is the right answer for a first pass.
Once the agent has authored the tools that work, flip the runtime into read-only mode. The agent can still call its existing tools, read files, and execute the JavaScript it already wrote. It cannot write new tools. It cannot rewrite its system prompt. The agent is now an artifact.
The tools.js and the markdown system prompt are the entire deliverable. Drop them into the DataRobot registry and workshop as a custom model, and you have a deployable, governed agent with a fully visible code surface. The exploration phase needs write access. The production phase does not.
The session was scheduled as a wild card. It turned into the cleanest internal argument we have had about what an agent platform should ship. Three takeaways.
Context is what you ship. A complete, well-structured spec for an external API outperforms a hand-rolled tool wrapped around the same API, because the spec preserves optionality the wrapper has already discarded. The implication is uncomfortable for product teams: the highest-leverage thing you can ship for the agentic era is not a new SDK or a new tool registry. It is excellent, copy-as-markdown documentation. The “copy page as markdown” button some open source projects have started adding is not a UX flourish. It is a deliberate concession to the fact that the reader is, increasingly, an agent. Make your docs loadable. Publish your OpenAPI specs. Keep them current. The agents will take it from there.
The sandbox is the unlock, not the loop. Most agent frameworks compete on orchestration, memory, and planning. The thing that decides whether the NL pattern is shippable is none of those. It is whether you can give the agent a place to execute code that you actually trust. Deno’s permission model does most of the work here. Restricted file types, restricted directories, restricted network egress, prefixed env vars. None of it is exotic. All of it has to be in place before the agent loop matters.
Best-in-class context beats best-in-class frameworks. The agents that work in production are not the ones with the most elaborate orchestration. They are the ones with the cleanest, most loadable, most agent-friendly documentation around them. Every minute spent on better markdown is worth ten minutes spent on a more sophisticated agent framework. Most teams have the priorities inverted, and the cost shows up as agents that look impressive in demos and fall over in deployment.
The implication for the DataRobot platform is direct. The registry and workshop already host custom models. The natural next step is a custom-model workflow that needs only a tools.js and a markdown system prompt, with the NL runtime providing the sandbox underneath. No environment configuration. The agent assembles what it needs from a spec you point it at, runs it inside a boundary your security team has already signed off on, and ships as a frozen artifact when it works.
Build Club runs weekly. Each session takes one volunteer driver, one hour, and an idea voted on by the audience. The format is deliberately unrehearsed: we build live, the build breaks live, and we fix it live. If you are building on DataRobot or thinking about enterprise-ready agents and want inspiration, this is the series for it.
The post Build an agent that writes its own tools appeared first on DataRobot.
Deborah Lupton / Pop Chips / Licenced by CC-BY 4.0.
Henrik I Christensen, Professor of Computer Science & Engineering at University of California San Diego, has recently released a global robotics technology roadmap. This position paper focuses on Asia, Europe, and America and outlines the current state-of-the-art in robotics, and highlights the main opportunities.
The roadmap draws on robotics research and industry data to identify a global technology trajectory for the decade 2025–2035. It integrates findings from leading robotics conferences (such as ICRA, IROS, RSS, CoRL), machine-learning venues (including NeurIPS, ICML), and journal publications, combined with market intelligence from trade organizations and regional government strategies. The document is structured for use by policymakers, technology strategists, research agencies, and industrial research and development leaders. It is based on a review of present research, industry statistics and numerous visits by Henrik to research labs across three continents.
Key headline findings of this roadmap are:
The 52-page comprehensive document covers the following sub-topics:
You can read the roadmap in full here.
AMD is aggressively reshaping local AI development with massive memory capabilities in its new Ryzen AI Halo platform and Max PRO processors, leaving competitors scrambling to match this raw power. Here in my home office in the high desert of […]
The post AMD Unleashes The Ryzen AI Halo Platform And Max PRO Processors To Revolutionize Local Agentic AI Development appeared first on TechSpective.
The second post from Build Club, our weekly live build session. A companion GitHub repo can be found here.
Your inbox is not the problem. The problem is that you are the person other people are waiting on.
Some of those messages need you specifically. Most of them need an answer you have already given six times this quarter, or context that lives in a doc you wrote last year, or a decision someone could make themselves with the right pointer. You cannot tell which is which until you read them. So the threads pile up. You drop some. Whatever you are responsible for moves slower because of it.
There is a pattern emerging for handling this: a digital twin agent that triages your inbound, drafts your first-pass responses, and only escalates the messages that actually need you. The pattern works. The hard part is not the agent. The hard part is shipping it without leaking a credential into a vector database on day one.
Carson Gee, a Senior Principal Software Engineer at DataRobot, kicked off DataRobot’s first Build Club session with the load-bearing fact: he has hundreds of unread messages. The session that followed walked through how he built a digital twin agent to triage them.
This post is the recipe. The short version is that you can stand up a digital twin agent on the DataRobot platform in about an hour. The honest version is that the last 20 minutes are the ones that matter, because that is where moderation, observability, and the boundary between “demo” and “production” get decided.
CaaS pinging Carson Gee to let him know he needs to make an engineering decision.
A digital twin is not a replacement for your judgment. It is a triage layer in front of it. Carson named it Carson-as-a-Service (CaaS), and it does four things.
CaaS listens in every Slack channel it is added to, but only on direct mentions. When someone @-mentions Carson, an agentic workflow categorizes the message: does this need Carson personally, can it be answered from his prior writing, or can it wait. If it needs him, it drafts a briefing and DMs him. If it doesn’t, it answers in his tone.
Prompt-driven scheduled jobs that can run on a custom cadence.
CaaS runs scheduled deep-research jobs on topics he is tracking. And maintains a database of Carson’s Confluence pages, blog posts, and saved memories, so the responses sound like him.
The asymmetry is favorable. An hour of setup buys back roughly 30 minutes a day of triage work, indefinitely, with the option to keep tuning. The pattern generalizes across roles. It works for the engineer who owns the on-call rotation, the product manager who fields every “is this on the roadmap” question, the manager whose calendar is booked by other people’s decisions, and the support lead whose inbox is full of questions they have answered before. The common shape is the same: a lot of repeat-pattern inbound, a small fraction that actually needs you, and no good way to tell them apart at a glance.
Everything below assumes you have a DataRobot account. You will also need to use the Agentic Starter application template. Related templates used are open-sourced and linked below.
The Agentic Starter application template gives you a FastAPI server, a deployment scaffold, and an LLM-backed agent template. You can fork it or access it directly in the DataRobot UI.
Carson’s twin is, structurally, the unmodified starter kit plus a Slack app, a vector database wired to a files API, and a personality prompt.
Use the DataRobot Slack app template to get the bot token and app token wired up. The one customization that matters: filter the Slack listener so the bot only acts on direct mentions. Without this, the bot logs every message in every channel it sits in, which is both an observability problem and a privacy problem.
This is the step that decides whether the twin sounds like you or like a generic LLM. Point the knowledge base at content you have actually authored: Confluence pages, blog drafts, meeting notes, the last six months of your own long-form Slack messages. Carson used an MCP connector to pull his Confluence space into the knowledge base, then layered a “memories” mechanism on top so he could append new context via a tool call from within Slack itself.
The knowledge base is backed by a DataRobot vector database, which gets attached to the LLM blueprint. Today, updates to the underlying files trigger a vector DB rebuild. Incremental updates are on the roadmap. In the meantime, batch your knowledge updates.
The default system prompt produces a generic assistant. That is not what you want. The first version of your twin will be too whimsical, too direct, or too earnest, and the second version is the one people actually want to talk to. You only learn the difference by deploying. Carson’s prompt explicitly instructs the model to be “direct, with character,” and includes opinions on technical topics he holds in real life. Yours should too.
This is the step the live audience forced into the build, and it is the one most teams skip. Here is what it looks like in practice.
DataRobot ships a global Presidio PII detection model. You can find it in DataRobot’s model registry and deploy from there. Then, on the custom model that backs your LLM blueprint, open the evaluation and moderation panel and attach the PII detector as a moderation model.
Set the moderation method to replace (which anonymizes detected entities like SSNs and credit card numbers with bracketed placeholders) or block (which short-circuits the response entirely). Tune the probability threshold based on how strict you want the failure mode to be. A threshold of 0.5 is sensitive enough to catch most obvious leaks; lower thresholds will start to false-positive on benign messages and make the twin feel broken.
Attach the moderation to the LLM Blueprint Model. This is the same evaluation-and-moderation panel as before, just attached one layer up so every agent call gets moderated. The UI generates a moderation_config.yaml in the Model’s assets.
Copy that YAML into the agent folder in your local project so the guardrail travels with your deployment. Smart diffing on the deployment side handles small revisions automatically; you only need to reattach the moderation by hand if you make a major change to the LLM Blueprint configuration.
Send the twin a few test prompts: an obviously benign one, one with a fake SSN, one with a fake credit card. Confirm both that the moderated response renders correctly in Slack and that the trace shows the moderation firing.
If you put the guardrail on the LLM, you will see the raw input in the agent trace and the moderated output downstream. If you put it on the agent, the trace will reflect the moderated input end to end. Decide which one your security review wants and document it.
The session was scheduled as a productivity demo. It turned into an extended tour of the moderation and observability surface area we ship to customers. That detour is the point. The productivity argument for a digital twin is not in dispute. The honest constraints on shipping one are.
Three takeaways from watching it play out live, in front of an audience that included security engineers.
The gap between “I built a thing for myself” and “I built a thing I can defend to security” is wider than it should be. The first version of any twin will not have the guardrails the second version needs. Plan for the moderation step. Do not treat it as polish.
Observability is a double-edged feature for an agent that lives in Slack. Tracing is what you want when debugging an agentic workflow. It is not what you want when someone has just pasted a credential into the bot. The right pattern is redacted display backed by encrypted-at-rest payload storage, scoped per trace by sensitivity.
The self-healing direction is real and worth experimenting with. Carson’s twin writes her own agent definitions back to the files API and reloads them as personalized variants, so the version of the twin talking to you can be tuned for you. That is not in the starter kit yet. It is in the next version of this build.
Build Club runs weekly. Each session takes one volunteer driver, one hour, and an idea voted on by the audience. The format is deliberately unrehearsed: we build live, the build breaks live, and we fix it live. If you are building on DataRobot or thinking about enterprise-ready agents and want inspiration, this is the series for it.
The post Build a digital twin agent (with guardrails) appeared first on DataRobot.