Discussion

Two weeks ago, if you told me I’d be leading a team of 50 to 100 people through high-stakes...#ai #hacktoberfest #careerdevelopment #opensource #software #coding #development #engineering #inclusive #community
Leading 100+ Engineers Through High-Stress Sprints: My Wild Hacktoberfest & HNG Story

Wie soll die SPD von der Linken Distanz zu Clan-Chefs fordern, wenn sie den bekennenden Kumpel eines Kriegsverbrechers in ihren Reihen duldet? https://taz.de/!6220771

Wie soll die SPD von der Linken Distanz zu Clan-Chefs fordern, wenn sie den bekennenden Kumpel eines Kriegsverbrechers in ihren Reihen duldet? https://taz.de/!6220771

TIL about #MerriBek

"building local web serving across neighbourhoods in order to provide affordable alternatives to big tech :: locally hosted web apps, built by volunteers, powered by renewables"

https://www.merri-bek.tech

#merribektech #LoResMesh

#リアリティ
#AI
#MMRコラム

AIとCGが現実そっくりの世界を大量生産する時代に、本物であることそのものが新しい希少価値になっていく

続きはこちらから🔽
monumental-movement.jp/column-why-r...

【コラム】 なぜ現実は特殊効果になりつつあるのか

These kinds of emoji changes are always fascinating to me from a textual preservation context. The tone of a message changes if you change the appearance of emoji characters - is the presentation of an archived messaging using something like this using the original visual context? The present day context?

The hairy heart was platform specific, but there are other changes like the gun emoji turning into a squirt gun - what does a message look like if you render it with a contemporary font?

RE: https://bsky.brid.gy/r/https://bsky.app/profile/did:plc:cyyd366g3hrxp5rynixm2mm3/post/3mxl5mahatc22

RIP hairy heart emoji (2013-2013)

#AI #DataCenters

RE: https://bsky.app/profile/did:plc:we7sidyj3b5or2r7trtpfzt7/post/3mxmke6wsg22m

It's going to be a long day in Wisconsin

#nfl

Cute Ffff Face Reaction

Hey people,

I need help to pay for our TROM servers for a year. I am really low on money recently and this time I am unsure how to bring it to the surface and make it float... I opened a campaign here donorbox.org/pay-for-our-trom-…

Please help me if you can. There are thousands of people using our services and taking value out of these TROM Projects. Would be a shame to let it dry out.

Thank you so much to everyone who can help or at least spread the word if possible!

---------

That's all. If you want to read more, here is my rant:

Recently the Universe has been all against me. Health problems for me and my family, Sasha split ways with me, financial issues...etc.. Is been so awful you can't imagine. I am currently in Romania because my father had the 5th stroke in less than a year and I am helping my parents move back to Spain basically. All while I am having tornadoes and tsunamis of stress and dark thoughts inside of my brain.

But, I will survive this assault too.

I was about to push myself to create a lot more for TROM. Was working on video scripts for a long-awaited (by me) video series; I was making videos for my Ride With Less channel; I was starting the work on a big and important TROM Article about AI....Was doing a lot! And I had to drop it all to come to Romania and solve this issue with my parents.

There is a lot to do and talk about, and somehow I am still here keeping TROM and myself alive. The Trade, this practice, is the orchestrator of most of our problems. What happens with AI for instance, the way is hyped and used, is meticulously directed by the same force of trade. The fact that humans may have less jobs because of "it", is also a problem that should not exist if trade was not a necessity to survive on this planet. AI, climate change, waste, stupid people, and so on, are a result of the same core issue that I try so hard to easily explain through TROM. So TROM is such an important project I argue. So important and in my view so unique, that is terribly incompatible with this fucked up society. And so, is such a war to try to keep this project, these ideas, alive and make them known.

People work, are tired, is Monday, is Tuesday, is Friday. Is another week. Come home, eat, do chores, watch some fantasy stories via these thingies we call movies or tv shows, scroll on phones, drink a beer, and move on. News about wars, endless TikTok seconds-long-AI-slop, the world is an asteroid traveling at immense speeds towards a black hole. Is so hard for projects like TROM to change the course of this. But like a fly on that asteroid I will hold on and buzz about it. Flap those wings until I can't. If I can't change the world I will for sure change myself, as a person. And hopefully a bunch of other people. We have plans...more than just the online ones. But for now they are wild (tho achievable) ideas I'd rather not talk about yet. However there is a lot of thinkering behind the scenes in regards to how to change the direction of this asteroid. At least in theory....

So yah, I HOPE I can get back to Spain and as soon as possible continue with my plan for TROM and myself. Without it, there is no "me".

I hope I can get help with this campaign so at least I have a bit of financial security for the upcoming months.

I swallowed so much stress this past months I wonder how I did not end up abusing drugs and giving up on life completely. But maybe what does not kill you...makes you stronger!? I hope so.

Life is a train that is not taking breaks. One day it will stop for us. But while is still going, I will try to make my train worth the ride despite so many roadblocks in my way.

Big thank you to everyone who supported this project one way or another. I am not dragging a dead horse, TROM is a strong and beautiful horse in my view, but is trapped in a forest of bullshit that is this society. We need to get that horse out, keep it fed and healthy meanwhile, and hope that others will notice it.

Take care people!

Unsubscribe View in browser

newsletter.tromsite.com/archiv…
RE: tiotrom.com/?p=8801

🏈 #NFL 😆

RE: https://bsky.app/profile/did:plc:ga6qjan2bmifjznyz7k7n7in/post/3mxmih4hgps2d

As a by the bye, this is the first time I’ve heard this new-normal concluding sentence in the audiobook wild:

“Please note that no part of this audiobook may be used or reproduced in any manner for the purpose of training artifical intelligence technologies or systems."

#AI
#Audiobooks

When Microsoft CEO Satya Nadella published an essay framing advanced language models as insider risks, technology commentary focused on political maneuvering and Washington rhetoric. Nadella adopted the term Super Intelligence while calling on enterprise buyers to treat foundation models like untrusted employees who require strict sandboxing, complete audit trails, and deterministic containment architectures. The engineering logic here is sound. Running non-deterministic models against corporate ledgers without runtime verification invites operational failure. The commercial mechanics behind the memo, however, tell a different story about enterprise distribution power.

The central problem for hyperscalers like Microsoft is value capture. When OpenAI and Anthropic raised capital at multibillion-dollar valuations, the underlying pitch assumed that the model would become the primary computing interface. In that world, an autonomous agent handles reasoning, selects tools, and interacts directly with corporate data. If the model acts as the sovereign operating layer, the laboratory that trains the weights extracts the bulk of the economic rent. The cloud hosting provider gets relegated to selling wholesale kilowatt-hours and GPU memory bandwidth, absorbing massive depreciation cycles while earning utility gross margins.

Nadella's proposed architecture counters that threat by decoupling intelligence from authority. In his framework, the model is merely a non-deterministic generator that must sit behind a deterministic control plane. The enterprise must never trust the model directly. Instead, every input and output passes through identity filters, policy enforcement engines, logging infrastructure, and manual kill switches. Nadella explicitly argued that the most trustworthy system is not the one with the best model, but the one where the enterprise has to trust the model the least.

Demoting the frontier model from an autonomous agent to an untrusted component alters the balance of power between the laboratory and the distributor. Once an enterprise accepts that models should be treated like volatile insider risks, reliance on a single frontier provider becomes an unacceptable vulnerability. Model diversity becomes a compliance requirement. If five different open-weight or proprietary models can be swapped into the same deterministic harness, model weights turn into interchangeable commodities. The pricing power of frontier labs collapses because their intelligence is stripped of execution authority.

The value does not evaporate. It shifts directly into the containment envelope. Managing the permissions, access logs, data isolation boundaries, and compliance audits for millions of corporate users requires existing identity infrastructure. Microsoft already sells that envelope through products like Entra, Purview, and Microsoft 365 Copilot. By persuading enterprise security officers that the frontier model is an insider threat, Microsoft ensures that the high-margin revenue stays with the governance platform that wraps the model, rather than flowing to the lab that trained it.

This posture also solves an immediate margin problem inside Microsoft's own balance sheet. Running frontier API calls inside fixed-price enterprise seats creates punishing compute costs. If corporate buyers believe that business workflows demand bleeding-edge reasoning from external laboratories, Microsoft must subsidize those tokens or raise subscription prices. By reframing safety around deterministic containment rather than model capability, Microsoft gives itself cover to swap expensive external models for cheaper, in-house distilled models. A smaller model that accomplishes a basic task inside an audited sandbox suddenly looks like prudent risk management rather than a compromise on quality.

Frontier laboratories face a difficult distribution squeeze. They depend on cloud partners for hundreds of thousands of specialized chips and billions of dollars in infrastructure funding. Yet those same partners are systematically designing the enterprise software layer to prevent the model from capturing the customer relationship. The laboratories are spending tens of billions of dollars to build sovereign intelligence, while the distributors build the tollbooths that treat that intelligence as a liability to be contained.#ai #economics #cloud #security #software #coding #development #engineering #inclusive #community
The Insider Risk Discount

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass ...#hacktoberfest #opensource #ai #webdev #software #coding #development #engineering #inclusive #community
WildSense: The Offline-First AI Nature Companion That Gets You Outdoors

A weekly digest from the Agentic Architect persistence kit: 7 senior C#/.NET rules for engineers keeping Cursor honest across sessions.#csharp #dotnet #ai #cursor #software #coding #development #engineering #inclusive #community
This week in Cursor + .NET — 7 rules (week ending October 11, 2026)

A Fortune 100 insurer spent $2.3 million and six months building a multi-agent claims system on a top frontier model. Clean orchestration, well-mapped workflows. The week after launch, it approved a $400,000 payout on a fraudulent claim.

The post-mortem didn't find a reasoning failure. It found three things:

• The agent had no memory of previous interactions with that claimant.
• The fraud-detection rules lived in a separate system it couldn't reach.
• Its system prompt was two sentences long: "You are a helpful insurance claims assistant. Process claims accurately and efficiently."The model was smart enough. It just wasn't given what it needed to decide.

This is the 2026 failure mode. Models are good, frameworks are mature, and teams are still shipping expensive demos, because the thing that determines decision quality is neither of those. It's whatever ends up in the context window at the moment of the call.

The mental model: LLM = CPU, context window = RAM, context engineering = the OS

Andrej Karpathy describes context engineering as "the delicate art and science of filling the context window with just the right information for the next step."

The analogy that makes this concrete for architects:

┌────────────────────────────────────────────────────┐
│ CONTEXT ENGINEERING (the operating system) │
│ decides what is loaded, when, and in what format │
│ │
│ ┌──────────────┐ ┌────────────────────┐ │
│ │ LLM (CPU) │◄──────►│ Context Window(RAM)│ │
│ │ reasons │ │ working memory for │ │
│ │ over input │ │ every decision │ │
│ └──────────────┘ └────────────────────┘ │
└────────────────────────────────────────────────────┘

When a laptop runs out of RAM, apps slow down, crash, and produce errors, even though the CPU is perfectly capable. An agent with a wrong or incomplete context window behaves the same way. Swapping in a faster CPU doesn't fix an OS that loads the wrong data.

Prompt engineering is a human writing a static string for a single turn. Context engineering is a system dynamically assembling context from multiple sources, at runtime, across multiple steps, where each step builds on the last. That difference is why prompt tweaking stalls out in production.

The seven components of agent context

When designing production agent systems, break context into seven components. Getting any one wrong can cascade.

flowchart TD
T[Trigger: user, agent, schedule, or event] --> A[Context Assembler]
SP[1. Instructions / System Prompt] --> A
LTM[2. Long-Term Memory] --> A
ST[3. State / Short-Term History] --> A
RAG[4. Retrieved Information] --> A
P[5. Prompt / Input] --> A
TL[6. Available Tools] --> A
A --> LLM[LLM reasoning]
LLM --> SO[7. Structured Output]
SO --> D1[Payment system]
SO --> D2[Audit log]
SO --> D3[Human reviewer]
SO -. updates .-> ST
SO -. updates .-> LTM

1. Instructions / system prompt

Your system prompt is a contract, not a vibe. In production it specifies role, boundaries, decision criteria, and escalation rules.

For the claims agent, that means the exact auto-approval thresholds, a mandatory fraud check before any payout above $50K, and escalation rules for edge cases. "Process claims accurately" is a demo prompt. Treat the real one as a versioned spec and review changes to it like code.

2. Long-term memory

This is where most enterprise agents quietly break. Agents need persistence across sessions: structured memory about entities, relationships, and past decisions, not just chat history.

A telecom example: a customer calls about a billing issue. With no long-term memory, the agent offers a standard $50 credit. With it, the context shows a $456K-a-year account with a history of escalations, and the right response is an executive-level retention intervention. The model is identical in both cases. The decision is not.

3. State / history (short-term memory)

In a multi-agent workflow, agents need to know what the other agents already did. Take a three-agent claims pipeline. Without state passing, agent 3 either redoes the work of agents 1 and 2 or decides without their findings. This is the amnesia problem.

State requirements also grow with autonomy. A routing agent passes classification metadata. A copilot passes draft responses. A resolution agent passes full execution context. If your state management doesn't evolve as you raise an agent's autonomy, context breaks.

4. Retrieved information (RAG)

RAG is table stakes. What matters is retrieval quality and volume discipline. Ask a financial-advisor agent "Can this client invest in private equity funds?" A bad pipeline dumps five loosely related compliance documents, around 8,000 tokens of legal text, into context, and the agent invents a policy interpretation. A good pipeline retrieves narrowly, ranks, trims, and attaches provenance.

Also treat retrieval as an attack surface. Every retrieved document is a potential injection vector. A poisoned document with hidden instructions gets processed as legitimate context (cross-domain prompt injection, XPIA).

# Sketch: sanitize and isolate retrieved content before assembly
def assemble_retrieved(docs, max_tokens=2000):
safe =
[] for d in rank(docs): # relevance-ranked
text = strip_instructions(d.text) # drop imperative/injected directives
safe.append(f"<doc id='{d.id}' source='{d.source}' trust='{d.trust}'>\n{text}\n</doc>")
return truncate("\n".join(safe), max_tokens)

Wrapping retrieved text in clearly delimited, labeled blocks and telling the model that content inside them is data, never instructions removes much of the attack surface.

5. Prompt / input

The trigger that starts the work. In enterprise systems the "user" is often another agent, a scheduled job, or an event from an external system, not a human typing. Design the input contract for those callers, not just for chat.

6. Available tools

Tools define what the agent can do, not just what it knows. Tool definitions in the context window tell the model which actions exist, which parameters they need, and what outputs to expect. This is where MCP matters: it makes tools discoverable and invokable consistently across services. An agent that knows it has a fraud-detection API, a claims database, and a document-verification service can plan around them. Keep definitions clean and deterministic, since sloppy tool descriptions are context noise.

7. Structured output

Downstream systems shouldn't parse prose. When the claims agent finishes, it should emit something like:

{
"decision": "flag_for_review",
"claim_id": "CLM-88213",
"risk_score": 0.87,
"reasoning": [
"Fraud API returned risk 0.87 (threshold 0.60)",
"Claimant has 3 prior claims in 14 months",
"Payout exceeds $50K: mandatory human review"
],
"audit": { "model": "<model-id>", "tools_used": ["fraud_check", "claims_db"] }
}

This output feeds the payment system, notification service, and audit log without human interpretation. The reasoning array gives you an auditable trail. The audit block tells compliance exactly which model and tools produced the decision. Combine it with low temperature, strict schemas, and validation gates. You aren't chasing identical text, you're designing for deterministic outcomes from non-deterministic components.

Walking one decision through the stack

At each step, the decision depends entirely on what's in the window:

1. Trigger. A customer files a claim. The orchestrator loads the system prompt, the claimant's history from long-term memory, the claim document via RAG, and the tool list (fraud check, payout system, escalation queue).
2. Reasoning. The claims agent calls the fraud tool, gets a risk score, and adds it to working context. It retrieves similar past claims and checks policy limits.
3. Decision. Approve (structured output to payments), flag (handoff with a full context summary), or deny (structured output with reasoning). Miss the fraud score, and you get a bad decision. Lose state between steps, and you get repeated or contradictory actions. Retrieve the wrong documents, and you get a hallucinated policy.

Why context is the root cause behind your other problems

The strongest claim in the source material is that reliability, security, cost, and platform fragmentation all trace back to context.

• Reliability. Non-determinism forces you to lock inputs (version prompts, system messages, retrieval sources), constrain outputs (schemas), and keep tool definitions stable. Every one of those is a context decision. Loose context means unstable behavior.
• Security. The "lethal trifecta" is access to private data, exposure to untrusted tokens, and an exfiltration path. A fake-invoice attack works because untrusted content entered the window unsanitized. That's a context-pipeline problem, not a model problem.
• Cost. A projected 10x ROI that landed at 2x wasn't a math error. It was a context cost miss. Bloated context inflates tokens per call, poor retrieval burns tokens on irrelevant documents, and missing memory forces repeated reasoning.
• Platform fragmentation. In the example, six pilots across four vendors had separate identity models, data contracts, retrieval patterns, and memory stores. No agent could assemble unified organizational context. The tooling wasn't the problem. Context couldn't flow. Context is the control plane of an agentic system. Engineer it deliberately or pay for it later.

A pre-ship checklist

Before an agent goes to production, answer these for each of the seven components:

Key Takeaways

• The model is rarely the failure point. A smart model with incomplete, stale, or unreachable context makes confident bad decisions.
• Treat context as an assembled artifact with seven components: system prompt, long-term memory, state, retrieved information, prompt, tools, and structured output.
• Long-term memory and state passing are where enterprise multi-agent systems most often break, so audit them first.
• Retrieval is both a quality lever and an attack surface. Sanitize, delimit, and budget what you inject.
• Reliability, security, cost, and platform fragmentation share one root cause. Fixing context fixes several problems at once. ## Closing question

If you audited your production agents today, which of the seven components would you find missing or hand-waved, and would you have caught it before the first costly decision?#ai #llm #agents #architecture #software #coding #development #engineering #inclusive #community
The Seven Components of Agent Context: A Production Checklist for Context Assembly

📈 MDS Trending Posts

⭐ Most Favorited

1] https://mastodon.social/@donni/117420177522085100 105⭐
2] https://mastodon.social/@renardboy/117419862800918193 32⭐
3] https://mastodon.social/@Tutanota/117422406187430864 29⭐
4] https://mastodon.social/@Daojoan/117420690981568427 27⭐
5] https://mastodon.social/@gazeshift/117420768850164962 15⭐

💬 Most Commenters

1] https://mastodon.social/@Lizette603_23/117419780947570429 30💬
2] https://mastodon.social/@donni/117420177522085100 30💬
3] https://mastodon.social/@ADignorantium/117419903050559537 8💬
4] https://mastodon.social/@gazeshift/117420768850164962 8💬
5] https://mastodon.social/@hsivonen/117421715785059717 7💬

♨️ Hot Hashes

1] #ai (15)
2] #nowplaying (8)
3] #photography (8)

#MDSTopPosts

I paid people to try and follow my README

Developers suck at writing documentation. We like to say RTFM but often there ain't no FM to R. At best we have a half-arsed collection of notes, some obsolete tips, and a link to a desolate forum full of people asking the same questions again and again. That's no way to treat our users.

I naïvely believe there's a better way. As I've written before, you should sit down and actually test your readme. Spin up a fresh Virtual Machine, go through what you've written, and see if it makes sense.

But it is really hard to ignore your own biases. Of course you know that certain commands require sudo and obviously when you wrote -foo you meant --foo and everyone knows that you have to reboot afterwards.

How do you get rid of those biases? I paid people!

As part of my NLnet grant application for ActivityBot, I said I wanted to test the install experience with real users and I was prepared to pay them €25 for an hour of their time. I stuck out the call on Mastodon, gathered a few people, and had a video call with them.

The format was simple. I explained that I was looking for feedback on the first-run experience. I knew that it wasn't perfect and actively wanted constructive criticism. I asked the volunteer to share their screen and, crucially, to speak aloud. Tell me what they were doing. What they didn't understand, what confused them, what delighted them, what frustrated them, etc.

I took notes by hand (fuck feeding the machine) and spent several hours being told what incorrect assumptions I'd made.

Amongst the highlights I discovered were:

• The link to the demo tool was wrong.
• Some people read a README in the terminal.
• What does it actually mean to rename a file?
• How do you rename a hidden file?
• Should a demo tool be available on the web or just the user's local machine?
• Why does some text explicitly need to be quoted and some not?
• My jokes aren't funny and are actively confusing.
• Some of the technical terminology needed explaining.
• The ordering of the different sections was confusing.
• I hadn't actually explained what the software would do.
• A whole section which was technically interesting to me was utterly confusing to everyone else.
• Not all web servers use permissions in the same way.

And on it went!

After each session I updated the README based on what people found difficult, then I re-tested it with the next person.

In total, I paid out around €150 to have a bunch of people criticise me to my face. Hey, cheaper than therapy, right?

I know someone is going to say "why not just ask an LLM to simulate a range of users?" The answer is very simple - I want to speak to real people. People are brilliant! They can make you laugh, you can see their cat when it wanders on to the call, they bring a unique perspective to the problem, and they're really happy when you give them a €25 voucher. Some will gladly do it for free and make you happy!

When I was doing technical writing for GOV.UK, all my beautiful prose was given a second-eye by another human. They eviscerated all my flowery phrases and turned the document into something more readable. They were the ones who caught the mistakes that no spell chequer could. They were able to have a proper conversation with me. More importantly, I could hear the frustration in their voice - that's the thing which lets you know a mistake needs to be corrected.

I don't claim that ActivityBot's README is now perfect - far from it - but it is now demonstrably easier to follow. Developers need to talk to real people. You don't have to pay them if you can't afford it - but find a few people who will talk aloud while they try to follow your instructions. I guarantee you that your README will become much better for it.