Sr. Content Developer at Microsoft, working remotely in PA, TechBash conference organizer, former Microsoft MVP, Husband, Dad and Geek.
159535 stories
·
33 followers

Microsoft Research and Paige Unveil PRISM 2 Pathology AI Model

1 Share

Microsoft Research and Paige’s PRISM 2 combines nearly 2.5 million pathology images with clinical language, creating a versatile AI model for cancer detection, biomarker prediction, and research.

The post Microsoft Research and Paige Unveil PRISM 2 Pathology AI Model appeared first on Cloud Wars.

Read the whole story
alvinashcraft
2 hours ago
reply
Pennsylvania, USA
Share this story
Delete

Zero to Agent in 30 Minutes: From Prompting to Loop Engineering with Ofer Mendelevitch

1 Share

Ofer Mendelevitch, head of developer relations at BAND, used this episode of Zero to Agent in 30 Minutes to trace how coding workflows can give agents progressively more room to work on their own. Using a package version resolver as a running example, he compared step-by-step prompting with loop engineering and then showed how multiple agents can collaborate on the same task.

How to move from prompting to multi-agent coding

  1. Start with explicit prompts in every step. Give the coding agent a specification and tell it what to implement. Ofer used a package version resolver with existing Python tests, then followed up with prompts to verify the implementation, resolve open questions, and add packaging.
  2. Define a verifiable goal. Loop engineering replaces a sequence of individual prompts with an end result the agent can check for itself. In Ofer’s example, the agent had to implement the resolver and continue iterating until it was ready to ship with packaging. The agent can inspect the code, add tests, run them, fix failures, and verify the package without waiting for another human prompt after each step. He demonstrated how this approach allowed the agent to work through the task until the goal was met.
  3. Add a second agent as a reviewer. Ofer then moved from a single coding agent to two collaborating agents (using Jam), assigning one to write the code and another to review it. The reviewer examined the specification, provided feedback, and ran additional checks, including adversarial probes. A larger group of coding agents could include agents focused on security, compliance, testing, frontend, backend, or DevOps. He also described using different coding agents together so that one model can challenge work produced by another.

The shift toward more autonomous coding workflows starts with how the work is framed. By defining goals agents can verify, giving them room to iterate, and assigning complementary agents to review the work, developers can reduce the amount of human intervention required and achieve higher quality for the code generated by the coding agents.

Coming next week

Next week, Craig Hewitt will host Zero to Agent in 30 Minutes to focus on building a voice-first workflow with OpenAI Codex. The episode will show how natural voice commands can operate a development environment, run subagent workers in parallel, and trigger browser-use workflows. It will also cover structured Codex project directories and hands-free system-level execution, with the developer directing the work by voice.



Read the whole story
alvinashcraft
2 hours ago
reply
Pennsylvania, USA
Share this story
Delete

Introducing Factory Fields

1 Share

Exciting news here at casa secretGeek. You're excited, Mrs secretGeek is excited, the little secretGeek kids are excited too. For the first time in a long time, I've released a new game!

I've put a free demo online at factory.secretgeek.net and you can buy the desktop version at itch.io

Factory fields is what the academics call a factory construction game, and it's based on food. It was inspired by "builderment", a factory game that has stolen so many of my hours. I know other people get hooked on "factorio" which is more famous, and in the same category.

The joy of factory fields is not what it adds to the genre, but what it takes away.

I've attempted to constrain the entire idea right down to the barest essentials.

As a result, we have a "1.5 dimensional" game. Conveyor belts can only convey cargo downwards and/or to the right, never upwards or to the left. As such you can never construct loops, only directed-acyclic-graphs (DAGs). It helps you think like a compiler.

animation of factory fields game with an apple orchard, wheat field, dairy farm, juice factory, wheat thresher, stone mill, cane thresher, milk separator and many conveyor belts

Another unique aspect of the implementation is that when cargo encounters a fork in the road it will randomly choose one path or the other, rather than the solution seen in games like builderment, where items will alternate between choices one and two. This is quite a dastardly feature. You might wait a long time for an item to be created, hoping it will be sent down one path, only to see it randomly allocated to the other. Or you might witness five items in a row all sent the same way, which is one of those million to one possibilities that somehow pop up nine times out of ten.

What I originally wanted to build was something much more epic. I've read and re-read books like these:

  • Guns, Germs and Steel — Jared Diamond
  • Sapiens — Yuval Noah Harari
  • The Dawn of Everything — David Graeber
  • Debt: The First 5000 Years — David Graeber

...and listened to about a million episodes of "The rest is history" podcast, plus, read a lot of rollicking sagas like:

  • Shogun (James Clavell)
  • The Baroque Cycle (Neal Stephenson)

...and so forth.

Hence, I wanted to make a game about all of evolution, technology, culture, craft, and trade; from the dawn of time up to the space age.

Instead (drum roll) — go have fun making some food, won't ya. Tell me what you think.

👟Play Factory Fields (free demo!) 💸Buy Factory Fields (itch.io)

↑ ↑ ↑ ↑ ↑ ↑ ↑


I could write a bunch of things about the implementation; what was easy, what was hard, what technology choices were involved, etc. If you like those sort of things, ask me in the comments below.

Read the whole story
alvinashcraft
2 hours ago
reply
Pennsylvania, USA
Share this story
Delete

The Throwaway API and the Foundational API

1 Share

I keep running into a new kind of company, and I want to name the pattern before it becomes the default. It is a company that ships an MCP server and a couple of SDKs, and calls that its API strategy. There is no real REST or GraphQL API underneath. There is no durable, documented, versioned contract that a human or a machine could build against without an agent in the loop. There is a server tuned for the agent of the moment, some generated client libraries, and a very confident launch post. I have started calling this the throwaway API — not as an insult, but as a category, because it is a genuinely different thing from what I would call a foundational API, and confusing the two is going to cost a lot of people a lot of money.

I can see this pattern because I spend my days looking at the whole landscape at once. Across APIs.io I am tracking more than a hundred thousand APIs, and I have spent a good part of this year profiling the roughly fourteen thousand companies sitting inside venture capital portfolios — the exact cohort most likely to chase whatever the current thing is. When you look at that many providers side by side, the split jumps out at you. Some companies have a foundational API: a real contract, described in OpenAPI, with a coherent resource model, that has been stable long enough to have consumers who are not the vendor. And a growing number have only the throwaway layer — an MCP server, a handful of SDKs, a landing page — sitting on top of nothing you can point to. From the outside, in the launch week, the two can look identical. Give it eighteen months and they could not be more different.

The foundational API is the water main. I made this argument at length when I called MCP last-mile plumbing, and the throwaway API is what happens when a company builds only the last few feet of pipe. It works, for exactly one consumer, for exactly as long as that consumer stays in fashion. The moment the agent runtime shifts, the protocol version turns over, or the model’s tool-calling behavior changes underneath them — and every one of those things will happen — the company with only a throwaway layer has to rebuild the connection to their own capabilities, because they never wrote down what those capabilities were in any form more durable than a server aimed at last quarter’s client. The company with a foundational API runs a new hose in an afternoon, because the thing that mattered was never the hose.

I understand exactly why the throwaway pattern is spreading, and it is not stupidity. It is incentive. If you are a fourteen-months-old company with a demo to give and a round to raise, an MCP server plus SDKs is the fastest possible path to something an investor can watch an agent use on stage. It demos beautifully. It ships in a sprint. And it lets you skip the slow, unglamorous, deeply valuable work of designing a real contract, governing it, versioning it, and standing behind it for years. The throwaway API optimizes for the demo. The foundational API optimizes for the decade. In a market that funds demos, you can see which one wins in the short run — and you can also see who is going to be quietly rebuilding their foundation in 2028 while telling everyone it is a “platform re-architecture.”

There is nothing wrong with the throwaway layer itself, and I want to be clear about that, because I ship one. API Evangelist and APIs.io both have MCP servers. The difference is that mine are thin, honest projections of real APIs that exist independently of any agent — the throwaway layer sits on top of a foundational one, which is exactly the arrangement I am recommending. The pattern only becomes a problem when the throwaway layer is the whole strategy, when there is nothing underneath it, when the SDKs are generated against a private surface no one else can reach and the MCP server is the only front door. That is not an API. That is a costume that looks like an API for the length of a keynote.

So if you are building right now, ask yourself one blunt question about your own stack: if every agent framework and every version of MCP vanished tomorrow, what would you have left? If the answer is a real, documented, versioned API that consumers can reach without a model in the loop, you built a foundation and put a nice last-mile connector on it, and you are going to be fine. If the answer is “a server and some SDKs and a landing page,” you built a throwaway and called it a strategy. I can see both patterns from where I sit, across a hundred thousand APIs, and I can already tell you which set of companies I would want to be integrating with in three years. Build the foundational one. Throw the throwaway layer on top, gladly. Just never mistake the second thing for the first.



Read the whole story
alvinashcraft
2 hours ago
reply
Pennsylvania, USA
Share this story
Delete

Investing in Women's Health Isn't a "Nice-to-Have"—It's Infrastructure. Here's Why.

1 Share

What if we told you that investing in women's health isn't just the right thing to do—it's the smart thing to do?

Marissa Fayer has spent 22 years turning that argument into action. She's the CEO and founder of the global nonprofit HerHealthEQ (deploying women's health equipment across 12 countries, serving 150,000 women) and the for-profit DeepLook Medical (imaging software that sees inside dense tissue). And now, she's the author of the new book Undervalued to Unavoidable: 

Women's Health as Infrastructure.

In this episode of HIT Like a Girl podcast, Marissa joins Joy Rios to make the case that women's health isn't a niche issue—it's the foundation of a functioning society.

Tune in to hear:

🔥 The Economic Argument: Why framing equity as an economic imperative moves money faster than moral arguments ever will.

💰 Move Money, Move the Needle: How consumers, investors, and philanthropists can redirect capital toward women-led companies and solutions.

📊 The Stats That Shocked a Banker: Why a top executive told Marissa, "I literally cannot unhear this."

🧠 From Data to Action: We have the data. Now what? Marissa breaks down small, actionable steps anyone can take—whether you're in a boardroom, at a clinic, or at your kitchen table.

⚠️ The 35-Minute Gap: Why it takes 35 minutes longer to diagnose a woman having a heart attack than a man—and what that means for women's health outcomes.

If you've ever wondered why we keep studying the problem without fixing it, this episode is your wake-up call.


Key Points with Timestamps

  • [02:45] The Multipreneur Mission: Marissa Fayer, CEO of HerHealthEQ (nonprofit) and DeepLook Medical (for-profit), and author of Undervalued to Unavoidable, explains that her daily drive comes from impacting women's health globally through better screening, technology, and access.

  • [05:30] The Numbers Don't Lie: We have the data on the massive disparities in women's health, but talking about the problem isn't enough. It’s time to move from conversation to action.

  • [06:50] The New Economic Argument: To get traction, frame women's health as an economic issue, not just an equity one. Companies with women in leadership and on boards are better investments and more effective with capital, making it a smarter business decision.

  • [09:20] How to "Move Money": Action includes moving capital toward women-owned brands, asking financial advisors to invest in women-led funds, and supporting healthcare companies that prioritize women.

  • [13:00] What Anyone Can Do Today: You don't have to be a CEO to make a difference. Small steps include asking why there are no women in a meeting, advocating for menopause and elder care policies in the workplace, or sending a form letter to a congressperson.

  • [15:00] The "I Can't Unhear It" Moment: A top bank executive told Marissa he couldn't stop thinking about how women are systematically left out of infrastructure decisions, which was the catalyst for changing his perspective.

  • [16:20] The 35-Minute Gap: It takes 35 minutes longer to diagnose a woman having a heart attack than a man, leading to irreparable harm. This is because symptoms in women (like back pain and stomach issues) are often dismissed or mistaken for other conditions.

  • [18:30] The High Cost of Exclusion: Women were excluded from clinical trials until 1993, and enrollment is still only at 40%. Marissa argues that it is far more costly to retrofit products than to design them with women in mind from the start.

  • [22:00] Women's Health is Infrastructure: Just as we invest in repairing roads and bridges, we must invest in the health of women—because they are the foundation of a functioning society.

  • [24:00] Beyond Conversation: While we still need to share the facts, the priority is action. This means voting with your money, time, and resources to support women's health and leadership.






Download audio: https://www.podtrac.com/pts/redirect.mp3/pdst.fm/e/traffic.megaphone.fm/DHT8725102302.mp3
Read the whole story
alvinashcraft
2 hours ago
reply
Pennsylvania, USA
Share this story
Delete

Brand Guidelines Are Ruining Your Website

1 Share

Why print-first brand systems break online, and how to push back without demanding a full rebrand.

I've been grumbling about this one for years, because although almost everyone now meets a brand through a screen, we're still handed identities designed for brochures, business cards, and the occasional exhibition stand, and then told to make the website behave itself. So this month I have a proper rant about it and Marcus does his best to talk me down, which he largely manages. We also get into top task analysis, which is one of my favorite research techniques, and the free app I've built because I got fed up running it the hard way.

App of the Week

Top Task Analysis is a free app I've built to make top task analysis considerably less painful, mainly because I'd spent years running it with a spreadsheet, a survey tool, and a fair amount of swearing.

How top task analysis works

Top task analysis is a technique Gerry McGovern came up with, and it works a bit like a survey except that it stops people from being greedy, because an ordinary survey hands you a long list of everything your users say they'd quite like and no sense whatsoever of what they'd actually walk over hot coals for. This forces them to prioritize, so you end up knowing which small handful of things the majority genuinely care about. Gerry's classic example is the Microsoft Office knowledge base that kept answering more and more questions and kept watching its satisfaction score slide, because the answers people actually needed were buried under a hundred they didn't.

I use it for all sorts, from shaping information architecture and working out which objections are worth answering, through to prioritizing features and deciding what has earned its place on a dashboard. Roughly 80% of your users want about 20% of what's on your site, and this is how you find the 20%.

What the app does

The reason nobody runs it as often as they should is that it needs at least 2 rounds, one to gather the tasks and another to vote on them, so the app handles both in a single pass. You seed it with a starter list from AI, from the client, or from whichever stakeholder shouts loudest, and it genuinely doesn't matter if that list is a bit rubbish, because visitors can search it, pick the 5 tasks that matter most to them, and add anything that's missing, which then appears for everyone who arrives after them. A second screen asks them to put their 5 in order, and the back end lets you see the lot, merge the 14 different ways people phrase the same task, and tidy up anything unhelpful. And yes, there's a profanity filter, because I have met the internet before.

Marcus made the good point that you want a segmentation question alongside it so you can see top tasks broken down by audience, which is already in there, and he also dug up a hospital trust site we worked on years back where we dropped the top 8 tasks straight under the main navigation. They're still sitting there 8 years later, which either says something flattering about the technique or something less flattering about how often that site gets touched.

Give it a go

It's free, because I did think about charging for it and then couldn't be arsed, which is not the sharpest business decision I've ever made. Have a play and tell me what's broken.

  • The app: Top Task Analysis
  • The step-by-step guide: Top Task Analysis: A Free App And Step-by-Step Guide
  • Feedback: paul@boagworld.com

When brand guidelines fight the web

Most people meet a brand through a screen these days, and yet the web is still treated as the place where you paste in whatever was designed for print. A branding agency mocks up a homepage that has never met a real sentence, the guidelines get signed off after 18 months and roughly all of somebody's political capital, and then some poor soul is handed the job of protecting it, at which point they'll defend an unreadable contrast ratio to the death because it's sitting on page 47 of the PDF. Consistency matters and I'm not arguing otherwise, but being consistently difficult to read isn't much of an achievement.

Marcus agreed with the general complaint and pointed out that Headscape has described itself as a brand interpreter for digital for something like 15 years now, for exactly this reason. He also told the story of a charity working with deafblind people whose shiny new sub-brand logo failed color contrast checks, and if I'd invented that example nobody would have believed me.

A brand should serve the organization and its audience, so the moment its rules make the website harder to use, those rules need to change.

What a brand actually is

A lot of the confusion comes from shrinking brand down to a logo, some colors, a typeface, and a photography style, when all of that is really just the clothes the organization turns up in. The brand itself is closer to a personality, made up of what the organization believes, how it talks, and how it treats people when nobody important is watching, and your copy and your customer service will say far more about that personality than a logo ever manages. Which means we have considerably more room to move online than the brand police like to let on.

Why print-first branding breaks online

Print gives a designer a beautifully controlled environment and the web gives them almost none of it, which is where most of the trouble starts. Somebody working on a poster knows the exact dimensions, the exact paper, and the exact ink, whereas online you're designing for a canvas you can't see, on screens that run from a cracked phone in bright sunlight to a 32 inch monitor with the brightness turned up to painful, at whatever zoom level somebody's eyesight demands that day. Pantone certainty becomes display roulette, where pale colors wash out, dark colors go muddy, and the elegant light gray text you signed off on a calibrated screen simply vanishes on a cheap laptop in a train carriage.

A poster sits still and a website refuses to

Then there's the small matter that a poster sits still and a website refuses to. Websites need hover states, focus indicators, error messages, forms, navigation that collapses gracefully, and buttons that look like buttons, and most traditional guidelines have nothing at all to say about any of it, because it never occurred to anyone in the room that it might come up. Add a few thousand combinations of real content, German translations that run half as long again, and pages that grow arms and legs over 3 years, and the handful of polished examples in the brand book stops being much use to anybody.

The familiar symptoms

The same problems keep turning up, and once you've noticed them you can't stop seeing them. There are the walls of capital letters that slow reading to a crawl, the brand color pairings with contrast so poor you can fail them by squinting, the decorative typefaces that turn to mush at small sizes, and the logos that only really work when they're the size of a bus, although responsive logos that simplify as they shrink are a lovely solution whenever anyone can be bothered to make one.

The typographic hierarchy problem

The one that genuinely baffles me, and I've run into it twice in recent months, is a brand book from an actual branding agency with no meaningful typographic hierarchy in it at all, as though headings were a passing fad we'd all agreed to ignore. Then come the layouts that can't cope with content nobody wrote in advance, the complete silence on containers and components, and the fact that there's frequently no contrasting color available for a call to action, because heaven forbid anybody should click on anything.

Where the cost lands

Any one of those on its own looks like a small compromise you can live with, but stack them up and the brand starts shoving people away from the website it was supposed to make them love. The cost lands on accessibility, on comprehension, on conversion, on trust, and eventually on the confidence of the designers themselves, who stop challenging the daft rules and start ignoring them when nobody's looking, which is how you end up with 9 versions of the brand in the wild and not one of them right.

What the attention test showed

I recently tested a brand-compliant homepage against a more flexible treatment using an AI attention prediction tool. The looser version came back with roughly 20% higher predicted clarity and focus, and predicted attention on the main call to action went up by more than 80%. These are modeled predictions rather than real conversion data, so please don't quote them as gospel, but they do give stakeholders something more interesting to argue about than personal taste. I was insufferable for the rest of the day.

Where Marcus and I disagree

I made the case for a digital-first approach, where you start with the personality and the principles rather than the letterhead, get UX, accessibility, content, and frontend people into the room while the decisions are still being made, design actual interface elements instead of stationery, and use the website as the place where the brand gets proven with real content on a small screen before it ever reaches print.

Marcus' counterargument

Marcus has tried that more than once and reckons it falls apart in practice, because running the digital interpretation alongside or ahead of the main branding project leaves nobody clearly in charge, and Headscape's opinion carries very little weight while the brand itself is still up in the air. He'd rather let the branding agency finish and get everything signed off, then arrive afterward with the client already warned that interpreting it for digital will mean changes, the typeface being the almost inevitable first casualty. He also pointed out that very few branding agencies build anything, which is a fair argument for keeping the two jobs apart.

Where we landed

I came round to that as the more practical position, with one condition attached, which is that whatever gets handed over has to be understood as a starting point for digital rather than a finished artifact that must never be questioned by anyone with a browser.

Consistency, not uniformity

The phrase I keep coming back to came from Neil Eastell at the National Trust years ago, and it's consistency, not uniformity. A brand system that works online is one that's clear about what has to stay fixed and honest about what's allowed to bend, so the logo keeps its essential form while picking up responsive versions, the core colors stay recognizable while gaining accessible digital variants, and the typographic personality survives a change of body typeface for the sake of download size or legibility, as long as nobody wanders off from a serif to a sans serif and hopes we won't spot it. Think of it as a jazz standard rather than a military march, where everyone is playing the same tune but there's room to improvise around it.

Questions worth asking

  • Which parts of this identity genuinely express the personality, and which are just habits nobody has questioned?
  • Was this rule written for screens, or copied across from print because it was already sitting in the document?
  • What user or business outcome does it protect, if any?
  • Does it still hold up on a small phone, at 200% zoom, in bright sunlight?
  • What does that logo honestly look like as a favicon?
  • How are you getting feedback on the brand from users rather than only from the board?
  • When brand compliance and readability disagree, which one wins, and who gets to decide?

The practical takeaway

Whatever you do, don't open with a demand for a rebrand, because that conversation is over before it starts and you'll be the difficult one for the rest of the project. Find the specific places where the brand rules and basic usability are openly at war, fix the ones doing the most damage, measure what changes, and use that evidence to earn permission for the bigger conversation later on. And when you hit a wall, offer to test the brand-safe version against a looser one and let the numbers do the arguing for you, because a brand guardian will happily fight your opinion all afternoon but they'll rarely take on their own users.

A brand exists to build recognition and trust, so when protecting the rules starts eating away at both, we're guarding the wrong thing entirely. Or, to put it the way I put it on the show, be a bit more flexible about your bloody brand guidelines.

And because Marcus got his plug in twice, here is Headscape.

Marcus' Joke

When a TV antenna married another TV antenna, the service wasn't great, but the reception was amazing!

Marcus fluffed the delivery, which if anything improved it.

Find The Latest Show Notes





Download audio: https://cdn.simplecast.com/media/audio/transcoded/eea3ff50-d316-4ff7-b8db-24c157eb37ff/ae88e41b-a26d-4404-8e81-f97bca80d60d/episodes/audio/group/bd754d64-e6e9-4c74-a461-a85ac412892d/group-item/55840531-f4db-427d-b95a-6ea7fdf75e10/128_default_tc.mp3?aid=rss_feed&feed=XJ3MbVN3
Read the whole story
alvinashcraft
2 hours ago
reply
Pennsylvania, USA
Share this story
Delete
Next Page of Stories