The interesting part was what happened on the way there. I started with two earlier papers, implemented and tested their ideas on the publicly released sales-conversation data, added support for Laya, and followed the machinery all the way down: tokenization, attention, probability heads, training objectives, calibration, synthetic data, and the code that turns a probability into an action.

That last distinction changed how I thought about the whole system.

Before going further, let me define what I mean. I built an open implementation of the decision-model approach and interface, and ported an inspectable open model. I did not have access to Jev’s private weights, recover its exact architecture, or establish benchmark equivalence. Jev’s public behavior does not uniquely identify its internals. Several architectures can implement that behavior.

What I can show you is how to build one, why it works, where it fails, and how to go beyond a JSON classifier into a system that can price uncertainty, acquire evidence, and audit the decisions it makes.

The source trail below is pinned to Brain revision 180a8890. The performance numbers are experiments I ran locally. You results may differ.

It started with a Reddit comment

It all started when I found this LocalLLaMA discussion. The author, Nandakishor M, pointed to earlier work on fast probability prediction and confidence-aware routing. The comment’s frustration was understandable: ideas can exist in an open paper long before a polished product makes them visible.

But chronology and similarity do not prove that the open soulution works. I had to see it working for myself. I treated the comment as a research lead, then went to the primary sources.

The first paper was SalesRLAgent, submitted March 30, 2025. It describes estimating sales-conversion probability over a conversation using embeddings, a policy/value architecture, synthetic conversations, and a supervised warm start followed by reinforcement learning. Its reported 96.7% accuracy is the paper’s result, not a result that I was able to reproduce.

The second paper was Confidence-Aware Routing, submitted September 23, 2025. It combines representation alignment, variation across internal layers, and a learned confidence estimator to choose between local generation, retrieval, a larger model, and human review. That is a routing proposal around language-model reliability, not a specification of Jev’s architecture.

Those papers gave me two useful questions: can a compact model emit a useful probability directly, and can software decide when that probability is sufficient to act?

I implemented the papers in Brain’s salesagent sample. This is an adaptation and a fully local one at that. I used local MiniLM representations instead of Azure embeddings, changed parts of the confidence estimator, and did not recreate the paper’s complete original training environment.

Then I added Laya, the independent open-weight model from Convai Innovations. Laya provided something the Jev announcement could not: executable architecture and training code that I could inspect and experiment with.

Here is the actual timeline in Brain:

TypeSafe announced Jev on September 15. The JSON end to end decision reproduction landed September 22. Within a few days I had a working system. A few days later I had a working solution.

The conceptual switch: stop generating the answer’s spelling

A typical autoregressive language model predicts the next token repeatedly:

The useful distinction is between generating an answer as a token sequence and computing a decision directly from a representation. An autoregressive model can generate a JSON answer, but that is only one way to use it. We can instead attach a classifier to its hidden states or, for suitable single-token labels, compare selected next-token logits. A decoder backbone does not force us to generate braces, label strings, or decimal probabilities.

A decision model instead computes numerical scores for an answer space supplied by the application:

Here, x is the state, q is the question, and O is the current option set. The ordinary software around the network serializes the resulting numbers as JSON.

In the architectures explored here, the application supplies the answer space and the network computes one scalar logit per candidate. A softmax converts those logits into a normalized vector, and ordinary software serializes the result. Avoiding output-token generation removes that decoding loop; it does not remove transformer computation. Any speed comparison must also account for backbone size, context length, number of candidates, batching, hardware, and the particular generative or classification baseline being compared.

The model does not have to learn where the closing brace belongs.

This also means the final layer need not be a fixed 77-class classifier. One scorer can be applied to three supplied options today and twelve different options tomorrow. The learned object is a compatibility function between evidence, a question, and a candidate answer.

TypeSafe describes Jev as returning probabilities in parallel and calls its training approach Reinforcement Learning for Calibrated Decisions, or RLCD. That public description motivates the interface.

There are three independent engineering choices here:

You can combine an encoder with supervised training. You can train an encoder with a policy gradient. You can attach a decision head to a decoder’s hidden states. None of these choices are obvious from just knowing that training uses “RL”.

And schema correctness is not factual correctness either. Restricting a model to approve, reject, and review prevents it from inventing a fourth string. It can still approve the wrong thing.

What the JSON actually means

Here is an illustrative Brain request:

The three primitives have different interpretations:

For a score question, the application assigns consecutive numerical indices to the supplied levels, starting at zero. Here, “no urgency” has index 0, “prompt response” has index 1, and “immediate action” has index 2. If the model returns probabilities [0.1, 0.6, 0.3], the expected index is 0 × 0.1 + 1 × 0.6 + 2 × 0.3 = 1.2. This is an average of the assigned indices.

The returned score is:

Yes, we are multiplying the first probability by zero. This is because we have assigned the first category a numerical score of zero. The result is not a 0–1 confidence, and it does not mean “120% urgent.” It is a location on the supplied three-level scale. If the levels are only ordinal, interpreting fractional distances as meaningful is an application convention.

Likewise, noul = 0.5 means equal probability of true and false. It does not mean “medium severity.” Severity needs a rubric.

Architecture one: encode the state once, let the options query it

My first implementation was in crates/decide.

It starts with the BERT-family encoder from sentence-transformers/all-MiniLM-L6-v2: six layers, hidden width 384, twelve attention heads, feed-forward width 1536, and about 22.7 million parameters. Brain implements its forward and backward computation locally.

MiniLM and Sentence-BERT are related parts of this checkpoint’s background, but they are not interchangeable names: MiniLM concerns transformer distillation, while Sentence-BERT concerns learning useful sentence representations.

The crucial design is late interaction. State text and question-option text are encoded separately with shared encoder weights. They meet in a small trainable attention head.

Tokenize and pack

The state passes through WordPiece tokenization. Long states are divided into overlapping windows. The current default is 256 tokens per span with 32 tokens of overlap, within the encoder’s 512-position table; these are configuration limits, not a promise that arbitrary-length input is free.

Each option becomes a slot carrying the question instructions, option name, and optional description. The implementation inserts real separator tokens. State tokens use segment ID 0 and slot tokens use segment ID 1.

All spans can be packed into one token buffer, but attention inside the encoder is restricted to each span. Packing is a throughput optimization; it must not let unrelated examples exchange information.

Preserve token representations

Let the encoded state have R token rows:

For S candidate slots, take the encoded [CLS] row of each:

This is an important implementation detail. The current head uses [CLS], even though this sentence-transformer checkpoint’s published pooling convention is mean pooling.

Compute queries, keys, and values

The head learns projections:

For each attention head, split the 384 features into 32-dimensional vectors. Candidate i then attends to state token j with

After concatenating the attention-head outputs, Brain computes

These equations follow head.rs, including its residual and shared linear scorer. There is no additional invented MLP in this head.

This is a dot-product. A query-key dot product produces a scalar attention score. Softmax turns the scores into weights. Weighted value vectors summarize the evidence relevant to that candidate, and a learned readout produces its logit.

The attention weights are useful diagnostics, but they are not automatically a faithful explanation of causality inside the model.

Normalize within each question

For a choice with K options:

Subtracting m avoids overflow and does not change the result.

The scorer is shared across candidates. It has no output row permanently assigned to “billing.” That is why new options can arrive at runtime.

For width 384, the head contains 3d2+6d+1=444,6733d2+6d+1=444,673 parameters: query projection, combined key/value projection, normalization, and scalar scorer. That small head is trainable independently when the encoder is frozen.

What state sharing gives us

Multiple questions reuse the state representation. Question-specific instructions stay with the slots, so adding a question does not require changing the state encoding.

But “no new state encode” does not mean zero extra work. New candidate text still needs encoding, head computation still costs something, and the current head calls have their own projection and dispatch overhead.

Windowing makes the encoder’s attention cost roughly linear in total state length for fixed window size: approximately O(Nwd) instead of O(N2d), ignoring projection costs and overlap constants. Candidate-to-state attention adds roughly O(SNd).

The tradeoff is real. Tokens in different windows do not contextualize one another inside the encoder. The head sees all their representations later, but that is not equivalent to deep, full-document attention. Window positions restart; the present head does not automatically recover global chronology. Overlap also duplicates tokens, which can alter their effective weighting.

One further property follows from the architecture: another candidate does not change candidate i’s raw score. It changes the denominator of the softmax. That makes option permutation straightforward, but it also means overlapping or duplicated candidates can distort probabilities. The caller must define a meaningful answer space.

The binary decision bug

The initial binary formulation used two slots: “the deal closes” and “the deal is lost.” The model returned approximately 0.5 for almost everything.

The obvious reaction would have been to train longer.

The actual issue was common-mode cancellation. In the recorded probe, the two slot representations had cosine similarity 0.989. Their queries read the state almost identically. The raw scores changed between conversations, but changed together.

A two-way softmax depends only on the difference:

If both logits contain the same useful state signal, subtracting them removes it. The probe recorded an absolute-score spread of 0.2895 but a difference spread of only 0.0066.

The repair was to score the proposition once:

That is the current noul path in Brain’s own Decide backend. It uses the proposition and optional true-description; the false-description is not separately encoded there. Laya uses a different two-option formulation, so this distinction matters when porting criteria between backends.

This is not a proof that binary softmax is defective. A sigmoid and a two-logit softmax have equivalent expressive power when parameterized appropriately. The failure was in this particular initialization, candidate representation, and training setup.

The fix commit records the change from 0.502 to 0.707 accuracy, and Brier score from 0.251 to 0.202. It is an unusually useful failure because it shows why a plausible architecture diagram does not mean that the output preserves the signal you care about.

What Laya actually implements

Laya takes a different route. Rather than encoding the state separately from each candidate, it packs the question, options, and state into a joint sequence

Those [MASK] positions are readout markers. This is not an autoregressive model filling missing words one token at a time.

The English root checkpoint that Brain ports uses ModernBERT-large. Its backbone has 28 layers and width 1024, alternating local and global attention. The ModernBERT paper describes the encoder family; the decision-specific head comes from Laya.

After the backbone, Laya:

1. Adds a learned question-type embedding to every token row.

2. Applies two extra pre-normalized transformer layers over the sequence.

3. Gathers one hidden vector per option at its [MASK] position.

4. Scores each gathered vector with LayerNorm, a linear layer, GELU, and a final scalar linear layer.

5. Applies temperature scaling and softmax over valid options.

The extra transformer layers use ReLU in their feed-forward blocks; the scorer uses GELU. The head’s normalization and linear layers have biases. Those details are easy to miss when reimplementing the model, and enough to break numerical parity.

Laya also has an act/escalate head. It combines the head’s [CLS] representation with four features: largest option probability, top-two margin, normalized entropy, and option count divided by 255. This is a separate learned output, not the API’s entropy-derived confidence field.

Brain implements the path in modernbert/src/laya.rs.

There are several practical consequences:

The English root Laya configuration used by Brain limits the packed sequence to 512 tokens, despite the backbone’s larger architectural context capacity. Question text and options consume part of that budget. The multilingual and typed-decisions checkpoints are not automatically covered by parity results for the root checkpoint.

Serialization also belongs to the model contract. Sorting JSON keys can change token order. Different spacing can change tokenization. Option truncation can erase the words that distinguish two choices. Brain preserves ordered JSON and reproduces the relevant sequence-building behavior rather than assuming semantically equivalent JSON is numerically equivalent input.

The sales experiment: useful results, and limitations

The public sales-conversation dataset contains synthetic conversations and annotations. Brain trains on prefixes: at turn t, it sees only turns up to t. Giving it the entire completed conversation would answer a different, much easier question.

The sample uses trajectory probabilities as training targets, not as input features. Its local representation also replaces the released cloud-embedding columns.

The recorded comparison is worth showing without embellishment:

The learned model lost on accuracy and had a better probability score. Brier combines reliability, discrimination, and outcome uncertainty; a lower Brier score alone does not establish that every probability is well calibrated. It is stronger evidence than accuracy alone, but reliability plots and subgroup checks are still needed.

The baseline investigations were revealing as well:

• A linear probe on frozen MiniLM representations reached 0.601 accuracy.

• A larger bge-base representation reached 0.581 in that experiment.

• A probe on the released Azure embeddings reached 0.798 on a separately stated 3,000/1,000 train/evaluation setup.

• Thresholding the final supplied trajectory annotation reached 0.982.

That last number is a warning about leakage. If an annotation that nearly reveals the outcome is admitted as an input feature, the benchmark can look spectacular without learning the intended prediction task.

It is not proof that the original paper leaked labels. And the Azure linear probe is not a proven information-theoretic ceiling. A better model, representation, split, or training procedure could change the result. The evidence supports the narrower conclusion that a bigger encoder did not solve this experiment, and simple controls were necessary to understand the gap.

The router had limits too: 92% of evaluated conversations fell in one routing band. A confidence-routing system that sends almost everything down the same path has not yet demonstrated much operational value.

For me, this was the first step beyond the hype: the outcome of an experiment can be valuable even when the result is “this part does not work well enough yet.”

What the paper-inspired sales pipeline in brain trains

There are three phases in ConversionPipeline:

The first two phases do not necessarily target the same distribution: a synthetic intermediate annotation and an eventual observed label can disagree. The recipe uses shorter conversations earlier, balances outcomes during sampling, and emphasizes later turns. These choices change the effective training distribution and need to be reflected in evaluation.

The policy module’s defaults include discount 0.92, clipping parameter 0.2, and entropy weight 0.01. Its actual update gates the reward gradient according to the ratio of the new committed probability to the stored probability. This is a custom conservative update, not a reproduction of a conventional stochastic actor-critic PPO loop. It has no learned value network. The entropy term also changes the optimum of the unregularized proper score, so I would not claim that this whole composite objective has an exact honesty guarantee.

For routing, Brain uses three signals:

Here estate​ is the mean-pooled local state representation. The executable calibration path fits the learned confidence network on that reference representation; it is not simply a copy of the paper’s generator-side final-state predictor. The projection P is fitted by ridge regression, and ϕ is a small two-layer network fitted against whether the model’s thresholded decision was correct.

Nonnegative fitted weights, normalized to sum to one, combine these signals. Thresholds at 0.75, 0.55, and 0.35 select act, retrieve, escalate, or human review. The variance ratio is squashed because the unsquashed ratio is not bounded like the other signals.

Why reward for correctness does not teach honest probabilities

Suppose a state leads to success 70% of the time. What should a probability model report?

The answer is 0.7. But an action policy rewarded for choosing the winning label has a different optimum.

Let r be the true success rate and let the policy choose “success” with probability p. Its expected correctness reward is

Differentiating with respect to pp gives 2r−1. If r>0.5, maximizing this reward pushes pp to 1. The policy learns to choose the more likely action, not to report how likely the event is.

This is the central distinction between a probability report and a stochastic action policy.

For probability estimation, use a proper scoring rule. With a binary Brier loss,

and Y∼Bernoulli(r),

The second term is irreducible uncertainty. The first is minimized at p=r.

Cross-entropy gives the same target:

When the target t is the true conditional distribution, its unique optimum is to report that distribution. Gneiting and Raftery provide the classic treatment.

Three training procedures

There is more than one training algorithm in this story. Calling all of them “RLCD” hides the differences an implementation needs.

A. Direct supervised probability fitting

Brain’s Decide backend supports

where

At γ=0, this is cross-entropy. At γ=0,λ=0, it is plain cross-entropy exactly. The SDK’s train_choices currently uses that plain-CE setting.

Focal loss with a positive exponent is generally not a proper probability scoring rule. It may improve an empirical calibration metric in a particular experiment, but that is something to measure. If preserving the probability optimum is the goal, start with CE, Brier, or their proper mixture rather than assuming focal is a calibration guarantee.

With softmax logits, the soft-target CE derivative is particularly simple:

Compute log probabilities with log-sum-exp. Do not construct them by flooring probabilities and then blindly differentiate the floor. Brain had a real saturated-gradient bug: the confidently wrong examples that most needed a corrective gradient were losing it.

For an exact oracle or a labeled static dataset, direct differentiation is the baseline. No environment rollout or critic is required.

B. The Laya-style sampled probability-report update

The public Laya fine-tuning notebook implements a different procedure, reproduced in Brain’s reinforce.rs.

First, run the network once to obtain logits zz. Then draw GG noisy variants:

The projection removes noise in the all-ones direction, because adding the same constant to every logit cannot change a softmax distribution. In padded batches, compute that mean over valid options only.

Each sampled distribution receives a reward. We are not sampling a long token response or an environment action at this stage.

The implementation’s reward is

The components are a floored logarithmic score, a spherical score, and an ordinal cumulative-distribution penalty. The last term makes placing probability two levels away more costly than placing it one level away. It belongs on ordered score questions, not an arbitrary list of department names.

Rewards become relative advantages:

Then the detached sampled logits are scored under a Gaussian centered on the current logits:

The training loss is

The omitted normalizing constant does not depend on the logits. The projected noise lives in the zero-sum subspace; the squared-distance expression supplies the corresponding mean-direction gradient.

The public fine-tuning defaults use four samples, noise annealed from 0.4 to 0.1, spherical weight 0.75, ordinal weight 1.0, and auxiliary CE weight 1.0. That is not pure reinforcement learning without supervised probability fitting.

Brain distinguishes those inspectable fine-tuning settings from the original pretraining settings described by the model card. The original full pretraining script is not what Brain does right now. Brain also standardizes advantages per question, while the notebook’s micro-batch standardization spans a larger group. This affects update scaling.

There is another mathematical caveat worth stating: the unfloored component scores have proper-scoring guarantees, but flooring the logarithmic term changes the objective in the extreme tails. The source calls the implemented reward strictly proper - this is not a global theorem for the clipped mixture. At a target component below the floor, the log term stops penalizing decreases in that component, while other components can still reward reallocating its mass. Sampling noise and finite-sample advantage normalization add further differences from direct minimization of a proper loss.

For a concrete counterexample, take a binary target with rare-event probability 10−6 and spherical weight 0.75. The implemented non-ordinal reward is about 0.749989040 at the truthful report, but about 0.749989540 when the rare-event report is halved. A non-truthful report scores higher. This does not make the method useless; it makes the global properness claim too strong. Calibration remains an empirical property to test, including on rare events.

Reinforcement learning for actions that affect future evidence

If the model decides whether to inspect a device, request a document, or move a robot, its action can affect what happens next. That is where a sequential environment and an action policy become relevant.

PPO is an action-policy optimization algorithm with a probability ratio and clipped surrogate; the original paper is a good starting point if you want to learn more about it.

Brain’s tiny evidence-acquisition demo samples one action and immediately updates from the same policy. Its ratio is therefore 1 when consumed, so clipping does not bind. This is currently not a full repeated-epoch PPO rollout loop (yet).

A sales transcript replay is different again: changing a reported conversion probability does not alter the already-recorded next customer message. Much of that task reduces to supervised or reward-based prediction over prefixes. If I want to learn which sales action changes the outcome, I need an environment or intervention data that actually connects actions to outcomes.

“Confidence” can be three different things unless you define it

Brain’s public choice/score confidence is

It is 0 for a uniform distribution and 1 for a point mass. It measures concentration relative to the available option count.

It is not the probability that the chosen answer is correct.

For p=[0.8,0.2], this confidence is about 0.278, not 0.8. A model can also be confidently wrong, and normalized entropy does not turn into an out-of-distribution detector simply because it is bounded by 0 and 1. Adding options can change it; normalization equalizes endpoints, not all semantics across option sets.

Keep these quantities distinct:

TypeSafe’s confidence documentation likewise describes confidence as derived from distribution shape, but does not establish that Brain’s exact formula is Jev’s internal implementation.

Calibration asks whether reported probabilities agree with observed frequencies under a specified evaluation distribution. In top-label calibration, predictions whose maximum probability is about 0.8 should be correct about 80% of the time.

That uses maximum probability, not normalized entropy, on the probability axis.

Synthetic data: decide what is true before deciding how to say it

A request to a large model such as “generate 100,000 decisions with confidence scores” can produce an impressive-looking dataset quickly. But most likely it will produce 100,000 examples of the generator agreeing with itself.

For a decision model, the data contract should come first:

1. Event: exactly what proposition or class is predicted?

2. Observation: what information is available at the decision time?

3. Horizon: by when will an outcome count as having happened?

4. Population: from which distribution are examples drawn?

5. Oracle: who or what determines the target, and with what uncertainty?

6. Options: are they mutually exclusive, exhaustive, and stable in meaning?

7. Action costs: which mistakes matter, and by how much?

“Will this device fail?” is incomplete. “Will this unit fail its next acceptance test under the specified operating conditions, given the measurements currently visible?” is a target you can start to label.

There are several legitimate data sources:

All are useful in the right setting. They are not equivalent evidence of real-world correctness.

For simulation, a useful distinction is between drawing a latent outcome and conditioning on evidence. If I sample a hidden fault, I may train on the sampled binary outcome. But the expected optimal forecast over identical observations is still their conditional event rate. If I can compute that conditional rate exactly, a soft target removes avoidable label noise.

The oracle must not reveal hidden state through the target distribution while pretending that distribution was determined by the learner’s observation. Nor should it label every ambiguous case 0.5: missing evidence implies a prior, and the prior may be 0.01 or 0.9

A complete small world with probabilities we can verify

Brain’s samples/learning/rlcd uses a deliberately small device-diagnosis world:

Here FF means faulty. The positive test rate is

Bayes’ rule gives

The full training targets, ordered as [healthy, faulty], are:

Note: positive means FAULTY here!

The posterior must average back to the prior:

Brain checks this information-refinement identity before training. It is a necessary consistency check, not a complete proof of an oracle: swapping posteriors or adding other mistakes can sometimes preserve the average. A stronger generator also checks its likelihood model, evidence partitions, and rendering semantics independently.

The existing sample trains the probability head with an equal-weight mixture of soft cross-entropy and squared posterior error (gamma=0, lambda=0.5). It supplies eight phrasings per evidence state, holds out two from each, and trains on the remaining eighteen strings. It demonstrates generalization to unseen wording of three known evidence classes. It does not establish general Bayesian reasoning over unseen priors, sensors, or domains.

A broader version should vary the prior, sensitivity, false-positive rate, and evidence pattern across entire held-out world families. If the model is expected to adapt to those parameters, make them visible in its input or make the deployment’s fixed world contract explicit. Otherwise you are changing the correct answer without giving the model a way to know.

For structured numerical evidence, exact Bayes computation in ordinary code is often preferable to teaching a text encoder arithmetic. The neural model can identify what evidence the text expresses; deterministic code can perform the calculation. Training the whole tiny world is useful here because it gives us an auditable learning experiment.

Generating a serious decision dataset

The following is the recipe I would build around the existing mechanisms. The current diagnosis sample is its smallest executable illustration, not an implementation of every stage below.

Start with semantic cases

Generate a structured case containing the world parameters, visible evidence, and permitted question. Compute the target from that case before rendering any prose.

For a deterministic workflow, the oracle may be a policy engine. For probabilistic diagnosis, it may be Bayes’ rule. For a game, it may be validated rollouts from restored states. When using a teacher model, label the oracle as a teacher and preserve its version and prompt.

For Monte Carlo targets, store the rollout count and uncertainty. A frequency of 0.7 from ten rollouts is not interchangeable with 0.7 from ten thousand. If using smoothing or a Bayesian posterior over rates, record the prior too.

Split before expanding into paraphrases

Partition by the underlying semantic family, conversation, customer, document, or world - not merely by rendered row. Then generate surface variations inside each partition.

Otherwise “the test was positive” can land in training while “the diagnostic result was positive” lands in test, and a million-row benchmark may contain only a few genuinely distinct cases.

Use separate training, model-selection validation, calibration, and final test sets. A small exploratory sample can use fewer partitions, but then the claims must be smaller too.

Use a renderer with restricted authority

A language model can help make cases linguistically varied. Give it visible evidence and stylistic instructions, not the hidden answer, and ask it to preserve the evidence exactly.

For example, a renderer instruction might be:

Rewrite the visible observations as a technician’s note. Preserve the test result, whether a test was performed, and every stated measurement. Add no diagnosis, cause, probability, or new observation. Return the note and a structured extraction of the observations you expressed.

Then validate the extraction against the original case. For high-assurance examples, templates or a controlled grammar are easier to verify than unrestricted paraphrasing. A second model is a useful reviewer, but two models can share the same misconception.

Generate irrelevant details independently of labels. If all faulty cases happen to mention a red enclosure, the model may learn enclosure color instead of diagnosis.

Design candidate sets deliberately

A dynamic-option model should see different option counts, permutations, and plausible distractors. Brain’s Banking77 sampler draws subsets that include the correct label and randomizes its position.

For one-hot targets, remapping the correct label is straightforward. For soft targets, dropping options changes the semantics:

• If the question explicitly conditions on the outcome being inside the subset, renormalize the retained probability mass.

• If the question asks for the actual outcome, preserve omitted mass with an other option or keep the full outcome set.

• If candidates overlap, a categorical softmax may be the wrong model. Use independent binary probabilities or redefine mutually exclusive outcomes.

Do not casually renormalize away the probability that none of the offered options is correct.

Also distinguish semantic labels from opaque IDs. A model receiving option_7 cannot infer an unseen meaning from that identifier. Give it descriptions, and hold out descriptions or ontology branches when testing genuine semantic transfer.

Add cases that expose shortcuts

Useful paired examples include:

A malicious instruction embedded in a document is another useful robustness case: the document is evidence to classify, not an authority allowed to redefine the classification task.

Validate at the boundary

Reject malformed examples before optimization: non-finite values, negative probabilities, sums outside tolerance, mismatched option counts, duplicate IDs, invalid score ordering, missing evidence, and targets indexed in the wrong option order.

Log why an example was rejected. Do not silently convert a broken target into a uniform distribution and call the dataset clean.

Finally, retain a representative evaluation distribution. Boundary-heavy and rare-event oversampling can help training, but reported risk must still be measured under the population weights relevant to deployment. If hard-label sampling changes class priors, account for that change rather than assuming the resulting probabilities remain calibrated.

What to freeze, and what to save

Start with a pretrained encoder. For a small domain dataset, train the head first. If the representation cannot separate the necessary distinctions, cautiously unfreeze encoder layers with a smaller learning rate.

Brain’s Decide choice-training rates are 2×10^−5 for the encoder and 10^−3 for the head. Its current Laya path freezes the backbone and uses a head schedule starting at 10^−3. These are implementation settings, not universal recommendations.

For a new domain, sweep learning rate and batch size together, select on validation data, and track probability metrics as well as classification. Check actual changed parameter norms. A decreasing loss is not proof that the intended tensors moved.

Frozen encoder outputs can be cached only while all relevant inputs, weights, tokenization, and stochastic behavior stay fixed. For joint-sequence Laya, changing option order changes the encoder input. For a training-mode encoder with dropout, casually caching one realization changes the training procedure.

Conclusion

I hope this was a good introduction to the decision model architecture that has been superhot in the past week. There is a lot more to it and a lot more experiments to do when it comes to applying it to new domains and new problems.

I’m continuously building out brain platform to support a steadily increasing set of building blocks that can be used to construct completely novel and fully local model architectures.

Join my Skool group to support the development of autonomous learning systems and stay up to date with latest work: https://www.skool.com/ai-software-engineering-1814

Last month I shipped over three hundred thousand lines of added code across thirteen repositories. I did not read most of it. If that sentence makes you uncomfortable, good - it should, and the discomfort is the whole subject of this article.

Here is the situation every serious user of AI agents is now in, whether they admit it or not. You point an agent at a task. Ninety seconds later it hands you back four hundred lines that compile, that are formatted correctly, that have plausible variable names and reasonable-looking structure, and that might be completely wrong. Not wrong in a way that jumps out. Wrong in a way that reads as right. The function that looks like it handles the edge case but inverts the condition. The inference backward pass that looks like calculus but is off by a transpose. The optimization that is genuinely faster and also silently changes the answer on one input in ten thousand.

You have two honest options, and both of them are traps.

The first trap is to read it all. Review every line the way you’d review a junior’s pull request. This feels responsible. It is also mathematically hopeless: the agent generates faster than you can read, so the instant you adopt this policy you have thrown away the entire reason you’re using an agent. You’ve hired a race car and you’re pushing it. Worse, human review is terrible at catching exactly the failures agents produce. We are good at spotting code that looks wrong. We are almost blind to code that looks right and isn’t - and “looks right and isn’t” is the agent’s native output.

The second trap is to rubber-stamp it. Skim the diff, note that it compiles and the happy-path test passes, and ship. This is what many people actually end up doing, and it is how you accumulate a codebase full of plausible landmines - bugs that each individually survived because nobody could see them, and that collectively detonate in production three weeks later when you no longer remember which of the ten thousand agent commits introduced them.

Both traps share one buried assumption: that the human’s job is to inspect the agent’s output. That assumption was fine when you wrote the code yourself and review was a second pair of eyes on a volume of code a human produced at human speed. It breaks completely at agent speed. The output is now too fast, too voluminous, and too plausible for eyeball inspection to be your correctness strategy. If inspecting the output is your plan, you don’t have a plan.

Put this on your fridge:

When an agent can write more correct-looking code in an hour than you can review in a week, your job stops being to review the code. Your job becomes to build the machine that decides whether the code is correct - a mechanical, unforgiving oracle that the agent’s output has to pass before you ever look at it - and to pin that oracle to an authority outside your own judgment. You stop reviewing outputs. You start authoring gates.

It is the only thing that works. I watched the same discipline independently save three completely unrelated projects in the same month - projects that do not share a single line of code. Without this bugs would have gone completely undetected even with human review (in fact human review would take an insanely long time and it would be impossible to find the bugs because they were very subtle).

Why “review harder” is the wrong instinct

The reason this is counterintuitive is that verification feels like a tax. Every hour spent building a test harness and the tooling you need is an hour not spent building the feature. It’s the same story as in the old days when it came to writing tests. People would not write tests because it costs extra but then anything that is untested is full of bugs developers simply missed because they did not write the tests.

In the old days bugs ended up in production because you did not think about writing tests that would have caught them - in the new days of AI bugs end up in production because of exactly the same reason but now it’s not just about writing tests - it is about writing complete validation harnesses so that agents can be protected against leaving bugs in the code. This is the whole new level of abstraction and a whole new discipline that supercedes writing tests (your agent should always have unit and integration tests - that’s non-negotiable. The question is what you have to develop in addition to that).

Agents remove the careful hands. What’s left writing the code is a system that is fluent, fast, tireless, and has no idea whether it is right. It will produce a beautiful implementation of the wrong algorithm with exactly the same confidence as the right one, and it will never once feel the difference, because without validation it simply has no feedback on whether it is doing things right or not. The careful-hands safeguard is gone, and the thing that replaced it cannot be trusted to self-assess.

That inverts the economics of verification completely. The harness is no longer a tax on building - it is the only remaining thing standing between the agent and your production system. It is not overhead. It is the load-bearing wall.

And once you see it that way, the highest-leverage work you can do stops being “write features” and becomes “build the oracle that lets the agent check its own features, so it comes back right by construction.“ You are not slowing the agent down. You are building the guardrail that lets you finally take your hands off it.

What you’ll get in the rest of this article

Next we will dive into the actual discipline, with the real examples from three domains that have nothing in common except that agents did most of the typing and the work is still correct:

• The one principle underneath all of it - the oracle is the bottleneck - and why it relocates your expertise from the diff into the gate.

• Pin to an external authority, never your own eyeballing - the parity harness, with real code that gates a from-scratch neural network against a reference implementation to six decimal places, and a CPU emulator that pins its behavior to the ARM manual by section number.

• The gradient-check principle - how to build a mechanical judge for the class of correctness you cannot see by reading, with the actual finite-difference checker that catches a wrong backward pass.

• The smallest possible proof - the overfit-one-batch gate, and why proving the trivial thing first is the cheapest bug-catch in existence.

• Two implementations, one oracle - differential testing, with the real harness that runs a program through an interpreter and a JIT and catches the compiler lying, plus the “miscompile detector” that turns one divergence into a precise single-instruction bug report.

• Fidelity gates on optimization - the rule that you don’t get to keep a speedup that changes the answer, with the code that enforces it.

• Pre-registration and honest grading - how to stop yourself (and the agent) from rationalizing a bad result into a good one, with a real committed-in- advance validation contract and the code that refuses to claim an edge that isn’t there.

• The ledger - how verified truth survives across agent sessions that each start from amnesia.

• The honest turn - why all of this is more work, not less, and why that’s exactly the point.

Read more

Most engineering teams that have adopted AI-assisted development are asking the wrong question. They ask: “How much does this cost?” The question they should be asking is: “How much does this cost per unit of work delivered?”

Those are very different questions, and the answer to the second one changes everything about how you should think about AI tooling budgets.

Read more

This is the story of how that happened: the technical decisions, the design patterns, the things I got right, and the things I had to rip out and rebuild.

Sven is a terminal-native AI coding agent. You give it a task in plain English and it works: it reads your files, runs your commands, writes code, and reports back. The core design constraint I set on day one was that it must ship as a single binary with zero runtime dependencies. No Python. No Node. No Docker required. You download one executable and it runs.

That constraint shaped everything.

Sven is at agentsven.com. Install it with:

curl -fsSL https://agentsven.com/install.sh | sh

Read more

This process is straightforward: GPU rig -> Conda + PyTorch -> llama.cpp -> download and quantize Qwen -> run on multi-GPU -> expose an OpenAI-compatible API -> run agent workflows against your local stack. We run this on dual Tesla P40 - the baseline. The bare minimum. If it works here, it will generally work on more modern hardware too - though newer cards may require newer drivers and framework builds (always run a smoke test). At the end you have a machine that runs real models, serves an API your tools already understand, and executes markdown workflows with a local CI agent. No SaaS. No mystery. Just silicon and your stack.

We will use sven as our agent - this is an CI-first agent that I’m developing entirely in Rust. It runs markdown scripts. It has a TUI and also has an initial embedded neovim support for editing the conversation.

Let’s build it

Read more

Everyone thinks building “AI agents” requires knowing frameworks like langchain, agno, crew AI or some other agent toolkit - and to a degree that’s true - but one thing is very much overlooked: generic agents that can execute language programs.

But the truth is much simpler:

All you need is a general purpose agent.

No need for agno.

No need for 500 lines of Python.

No need to build MCP tools.

At least not for getting every day programming work done.

All you need is just markdown files, instructions, and a generic agent with basic tools that can execute them.

And once you understand this, you start using language programs to automate everything you do, and you start seeing general purpose LLM agents as the world’s most flexible runtime environment.

Let’s unpack this.

Natural Language Is The New Universal Glue

Programming languages are great at solving problems predictably.

Existing cli tools are excellent at doing everyday tasks.

All cli tools come with built in help.

LLMs are trained on massive amounts of open source documentation that explains to them how to use pretty much any open tool out there.

But we humans all think in natural language, not shell scripts.

Until now, those worlds were separate.

We had to transform our thoughts into shell script to orchestrate things.

These shell scripts were rigid - created carefully for a specific set of tasks.

Today - these the world of rigid tools and the world of natural langauge are stackable.

Here’s the model:

• Python is how you glue low level libraries together.

• Rust/C/C++ is how you code real programming stuff.

• Language Scripting is how you orchestrate everything else from the top - like a commander issuing mission plans to a team of specialists.

This is not a replacement for coders.

It’s a layer above.

A glue layer.

A process layer.

A coordination layer.

A “ask user these questions and then based on the answers orchestrate all the tools you have to produce this result. Here is how.” layer.

It’s stupidly simple:

👉 You create a folder of markdown files

You organize your language program just like a normal program - the idea is that the agent will only load instructions that it needs for the task.

Each part of the process is a “module,” a “library,” a “playbook,” a “skill.”

👉 You write your orchestration logic in plain language

Not as prompts

but as programs with instructions on what should be done and how.

What tools to call.

What outputs to produce.

What to use as inputs to the process.

What stuff to ask user to provide.

👉 The agent loads whichever markdown files make sense for the task

That’s it.

Just hierarchical natural language + tools that the general purpose agent already has.

And suddenly, you’re programming at a level of abstraction that never existed before.

Why It’s So Overlooked

Everyone overcomplicates “agents” because they think in traditional engineering mental models.

They think they need to code it in agno, have system prompts in a database and all other kinds of additional comlexity.

But all you really have to do is get a general purpose agent that can:

• Read files: so you can tell it what to read.

• Write files: so you can tell it where to save intermediate stuff.

• Call shell commands: so you can tell it how to process stuff.

The model can figure out how to drill down and get the right instructions if you just give it a few basic tools to do so.

All currently available general purpose agents already have these tools and more.

You can of course also implement additional cli tools that you need and explain to the agent how to use them in plain english. Most of the time you don’t even need to write them - agent will just apt-get install the tools it needs.

All you do is explain the process of how to think about a task and how to do it step by step. This is where models often lack insight. You have to explain how you want something done.

The model figures out the rest.

It’s a mindset shift:

Old programming: Tell the computer exactly how to do something.

Language scripting: Tell the model how to think about the task and where further instructions live.

The LLM handles the flow. You structure the knowledge into a hierarchy of folders and markdown files.

Your “program” becomes a directory of meaning - not a single monolithic system prompt

The agent decides:

• which instruction files to load

• which rules apply

• which tools to use

• which sequence of actions fits the goal

You write the logic of how to do that - in plain language.

The model executes it like a chef navigating a kitchen full of labeled ingredients.

This is why building agents is suddenly easy.

The “intelligence” isn’t in custom code.

It’s in how you structure hierarchical instructions.

What a Language Program Looks Like

Imagine a folder like this:

.cursro/commands/
    bot.md
    /bot
        plan.md
        implement.md
        review.md
        test.md

bot.md tells the agent:

• what abilities it has

• where detailed instructions live

• how to reason about tasks

• when to load which files

User just runs /bot analyze code in folder and write output report to report.pdf and the language scripts already cover instructions on how to go about doing the analysis and how to produce a beautiful pdf.

Each markdown file is a reusable semantic unit - a modular idea.

This ensures that it scales: the model doesn’t need to load all instructions into context at once.

This is why it’s simple.

This is why it works across ANY model with tools: Codex, Cursor, Claude Code, GPT Agents.. you name it. Even agno or crew ai - but really just by you coding a general purpose agent in these tools. Everything else can be scripted in natural language.

You write one universal language program.

Every model understands it.

It’s the first time we’ve had a portable brain runtime.

This isn’t about replacing developers. This isn’t about no-code fantasy land. This isn’t about “AI takes over programming.”

It’s about introducing the first universal command layer for computers.

For 60 years, we told computers what to do in rigorously structured languages. For the first time ever...

We can instruct computers in any language.

Not chaotically. Not conversationally. But systematically.

With structure.

With modularity.

With hierarchy.

Writing documentation that executes.

🔥 Language scripting is the new daily normal

A way to orchestrate tools, logic, context, and workflows using the medium humans think in: natural language.

Before LLMs there was never a semantic runtime.

A system that could interpret instructions and adopt along the way.

And now this is where we are.

Once you see this, you can’t unsee it.

I made it in two afternoons by learning from Jamie Heinrich and his absolutely fantastic group called AI Filmmaking on Skool.

Jamie uses AI like a pro: he is an educated filmmaker who has been struggling to get his ideas out (not surprisingly, considering how very hard it is to make videos) - but that all changed with AI. Key point though: he knows filmmaking. That’s his most valuable skill. He then uses the proven filmmaking process and accelerates the details using AI. Which is exactly how it should work!

Honestly, when it comes to abstract stuff like the idea I wanted to communicate in Cursor Control - it would be bonecrushingly hard to create a video like that without help from AI. Not just the whole filming, actors, clips that communicate - the hardest part is communicating an abstract idea in concrete terms in the first place - it would be crazy hard to do and cost a fortune too. But not anymore! By integrating AI into the process it becomes a lot easier.

Don’t get me wrong. It still takes work. Every single sentence needs to be passed through TTS more than once to get it to flow. AI is not creating the video - you are. AI is just there to remove all the ridiculously hard crap like filming and voiceover. You still write the script, you still develop a scene progression, you still generate clips (sometimes multiple times), you still stitch it all together (I used Kdenlive). You still make the music (also generated but carefully chosen to match the emotion of the video). It’s still a lot of work. But it’s not nearly as much work as it would have been without the AI tools.

Jamie’s group is amazing. If you want to learn the state of the art AI video creation then Jamie is the top goto guy right now. Knowing the video creation process and then automating the details with AI makes the whole process so much fun!

Join his AI Filmmaking community on Skool and make a video yourself.

It’s about time that I share this with you.

These tools have been around for a while - but never have they become so good that it was possible to close the loop on the process completely.

This is not like another “Vibe Coding” tutorial because I base it on a solid foundation of years of software development experience. I’m not interested in saying “build me an app” and having AI produce an app. I’m interested in using AI to automate parts of the process so that I can then stitch the results together into something that resembles the idea that I had in mind when I started. This is where AI tools truly shine!

I don’t believe that AI can produce good software all by itself. I do however believe that AI is an invaluable tool that fills in the gaps in any existing development process - or any process in fact that involves media (text, images, video etc)

The correct way to look at AI is it having a similar function to professional engineering tools like “Matlab” or “Altium Designer” or “VSCode” or even “Vim” and “Emacs”. These tools came at a time when development processes were manual an inefficient. These tools multiplied efficiency for developers who already knew the process.

The same thing is true for AI tools. They don’t replace the process - they replace the manual, tedious editing work that just takes time away from thinking about how things should fit together in the project.

In my new group that I have just set up on Skool I will share with you my process for using AI tools to produce top quality merge requests at a fraction of the time it takes to do it manually.

I will cover the process and show you hands on demonstrations of the process - but you have to understand that understanding the process - from planning to finished MR - is what matters the most. You can use the same process then for any kind of software development task that you are working on and you will reap the benefits.

I have seen in my own experience over and over again that AI can produce 99.99% correct code if only it is given all the details. The correct input (context) matters - A LOT - for a good output. In this course I will show you how to assemble the correct input - every step of the way.

It’s not about “Vibe Coding” - it’s about following a process that takes you from idea to finished merge request that matters. The sum total of all merge requests is your product. It is my belief that if you can master the process of creating one MR, you can master the process of creating a product.

Most technical debt comes from slop in individual merge requests summed up over time. We want to remove the slop and focus on implementing features - FAST!

Join my AI Software Engineering group for just $5 and be part of this community with me. To access the course, you can then click “Classroom” and you will find it there!

The transformer architecture has become the foundation of modern language models. In this post, we’ll walk through the transformer implementation, explaining each component step-by-step with concrete code examples and tensor shapes.

I will first guide you through the implementation of the transformer and then we will create small models that can learn to do cool stuff. The models I will show you in this article are:

• 0.1M parameter model that can reverse strings (and how to train it)

• ~28M parameter model that can evaluate mathematical expressions

• 3.15M parameter model that translates word expressions to symbolic math

We will train all these models from scratch very quickly.

Reverser model:

We will be training the model from scratch and the results we are going to get will look progressively better like this:

the quick brown fox=xof ,mtohxmrfu (at first partially correct)
....
the quick brown fox=xof nworb kciuq eht (finally fully correct)

Note that none of these examples are present in the training data. The training data are just random strings.

Training data:

gowmkugwhttut=tutthwgukmwog
ImfxVciDdVvp=pvVdDicVxfmI
pGA=AGp
rbgyxsbob=bobsxygbr

Math interpreter:

The results of the model trained to do math will look like this:

100-50+25=75 ✓
2+4-8*10=-78 ✗ (correct answer -74)
7*8+12=68 ✓
99/3-11=23 ✗ (correct answer 22)
10.5*4.2-8.75=35.65 ✗ (corret answer 35.65)
100/4+12.5=37.5 ✓
100/4+12.5=36.5 ✗

Here the training data are random expressions with correct answers:

25/-27=-0.9259
-5.3*-662=3508.6
9.99-53=-43.01
-45-5=-50
10.4579+-119.3=-108.8421

Math translator:

The third model we will train is going to translate word phrases to math expressions:

seventyone divided by six plus threehundredfive=71/6+305
one divided by eight plus six times ninetyseven=1/8+6*97
eight times seventyone=8*71
negativetwelve times fifteen divided by seventeen=-12*15/17
negativetwentyone plus eight times nine minus three=-21+8*9-3
seventeen plus fortythree divided by sixtyfour=17+43/64

This training objective is important because it is very easy to then extend this model with an additional step that evaluates the expression using a python function. Thus giving us a system that can take word expressions as input and produce correct mathematical answers.

It’s not going to be perfect with the tiny models we will be training today, but the point is to learn how the modelhe architecture works and behaves and to learn how to train a model from scratch.

The model learns to infer the answers solely based on prediction of next token - yet it guesses answers that are surprisingly close to the correct answer even with as few as 80M parameters.

What we are doing essentially is system identification for a system that has in input signal before the = and we want to have a model of that signal that allows us to predict values after the =.

If you understand this concept, you will be able to train any model for any domain from scratch and get good results eventually. A more complex system obviously requires more complex model and more compute to train it - but the core principles scale really well.

What you will notice is that the last model will converge very quickly - this is because there is a lot of important structured information encoded in the tokens before the = sign which can then be used to compute only a few output tokens. Thus the training data is very saturated in important information that can be learned.

The purpose of this post is to give you a really good understanding of how the transformer works, how to train it on a dataset of examples and how to handle the correct training objective during training so that you don’t include irrelevant information in your calculation of error between desired result and actual result.

Read more

Subscribe: Click Here

Key takeaways:

• Context is (nearly) everything: if you can provide all information needed to implement a coding task, AI can implement it.

• A good plan saves a lot of back and forth chitchatting

• Sometimes switching model solves a problem quicker - but providing context is just as important.

• Tests constrain the generation to produce desired behaviors - and maintain them over time.

• MCP tools bridge the gap between AI and your services (almost) entirely.

• Onboarding new developers into your team should take days in 2025, not months.

• Recording a podcast with an agent as host is pretty decent (except for tone fluctuations)

When you don’t get correct results from AI it usually means:

• There is so much complexity in your code even ai wouldn’t get it.

• You did not provide context

• You did not explain what the end result should look like.

• You forgot to write tests.

• You have not refined the plan

Modern MCP (Model Context Protocol) servers require robust authentication that balances security with developer experience. As organizations increasingly adopt AI-assisted development tools, securing these servers becomes critical for protecting sensitive data and ensuring compliance.

In this issue of Agentic Engineering Newsletter, I will show you how to implement enterprise-grade OIDC authentication for MCP servers using Keycloak, FastAPI, and FastMCP. You’ll learn production-validated patterns from a real-world implementation, complete with examples, code samples and explanations of how this works.

If you are a platform engineer, backend developer, or DevOps implementing secure MCP servers in enterprise environments, I think you will find this guide very useful.

We will use Keycloak as our IDP (Identity provider), simply because it is very feature rich and very easy to setup. The principles however are the same for any IDP that you choose to use. One huge benefit of setting up your own is that you have full control over all of its functionality and it is easier to learn how IDP works when you can tweak many settings and observe the results.

Using an IDP allows you to completely offload user management and authentication from your MCP server (the server is referred to as having the role of “resource server”) and focus on the features that you want to develop while having top grade granular access control available to you.

The access control is handled through tokens that are signed by the IDP and which contain claims which you can then use in your MCP server to decide what the user has access to. Your MCP server can easily verify that the token has been issued by the IDP by verifying its signature against the IDP provided public keys.

Table of Contents

• 1️⃣ Architecture Overview: Modern OAuth 2.1 + OIDC for MCP

• 2️⃣ OAuth 2.1 & RFC 9700 Security Standards (2025)

• 3️⃣ Keycloak realm and client setup

• 4️⃣ OIDC flow in the server (authorization, token, validation)

• 5️⃣ Token validation and claims usage

• 6️⃣ Role-based authorization in MCP tools

• 7️⃣ Local development and testing

• 8️⃣ MCP Server: with OAuth integration towards IDP

• 9️⃣ MCP Client: to test our MCP server

• 🔟 Further resources

Let’s jump right into it!

Read more

We will cover the following areas of software development process and how AI can be used to increase productivity in each step of the way:

1. Before Coding: Requirements and Planning with AI: Learn how AI can help analyze requirements, break down tasks, and design solutions before writing any code.

2. Test-Driven Development with AI: Discover how AI can assist in generating test cases and guiding you through the TDD cycle of red, green, and refactor phases.

3. Writing Code with AI: Explore effective prompting techniques for generating high-quality code and using AI for code reviews and refactoring.

4. After Coding: Quality Assurance with AI: Understand how AI can help design testing strategies, perform security analysis, and optimize performance post-coding.

5. Code Review Preparation with AI: See how AI can assist in creating detailed pull request descriptions and updating documentation for code reviews.

6. Collaboration & Review with AI: Find out how AI can enhance the code review process and help resolve conflicts during collaboration.

7. CI/CD and Release Readiness with AI: Learn to use AI for generating release notes and optimizing CI/CD pipelines for smoother deployments.

8. Post-Merge: Monitoring and Maintenance with AI: Discover AI's role in log analysis and incident response after code is merged into production.

9. Continuous Improvement with AI: Explore how AI can assist in analyzing technical debt and facilitating team retrospectives for ongoing improvement.

Read more

This is going to be a long one… 1500+ lines..

I have been using cursor daily in my development work and it is by far the most versatile agent out there. For us developers, everything is text. So we don’t care about UI. Server clusters are text, apps are text, automation is text, everything we do on the computer is text. And AI models are great with text. And cursor is the best tool yet to work with text. So there you have it. This deep dive will be a deep dive into cursor and how we can truly get the most value out of it!

Cursor is absolutely INSANE!

The AI-Powered Development Revolution

Year 2025 marks the age when AI-assisted software development has truly arrived, and it’s transforming how we write, debug, and optimize code. Tools like Cursor, GitHub Copilot, and other AI agents aren’t just fancy autocomplete - they have become true coding partners that dramatically accelerate development while maintaining (and often improving) code quality.

Recent McKinsey research shows that developers can complete coding tasks up to twice as fast with generative AI tools, with documenting code functionality taking half the time, writing new code in nearly half the time, and code refactoring in two-thirds the time. But here’s the crucial insight: the tools are only as good as the skills of the engineers using them.

💡 Pro Tip from the Trenches: As one experienced developer put it, “I’ve been Vibe coding like crazy lately… you’re using this agent based coding in cursor or Windsurf… I am literally trying to get AI to write the entire application end to end.” However, the key to success isn’t just letting AI run wild - it’s having a structured approach with clear rules and boundaries where you direct its output every step of the way and make sure that it is on track.

This guide distills insights from sources including GitHub’s official documentation, McKinsey’s research studies, industry best practices repositories, and analysis of the most valuable YouTube tutorials on this topic to give you a comprehensive roadmap for maximizing your effectiveness with AI based coding tools.

1. Master the Art of Strategic Prompting

The Foundation of Effective AI Collaboration

The difference between getting mediocre and really good results with AI coding agents often comes down to one critical skill: prompt engineering. It’s about structuring your requests so the AI can understand context, requirements, and constraints. A good prompt is just like a clear command to a human developer. If the command is clear and easy to understand, the developer will be able to produce the requested result.

The level of understanding comes down to information density of the prompt.

Best Practices for Prompting:

Be Specific and Detailed Instead of: “Fix this function” Try: “Refactor this function to use a for...of loop, add proper error handling for null values, and ensure it follows TypeScript best practices with appropriate type annotations.”

Provide Rich Context - Clearly state the problem you’re solving - Include relevant code snippets or file references: this will allow the model to request to read the files to get more information. - Specify programming language, frameworks, and libraries you want to use - Outline constraints like performance requirements or design patterns or coding standards. - Mention your target environment (browser, Node.js, mobile, resource constrained embedded etc.)

Use the “Problem-Solution-Validation” Framework 1. Problem Statement: “I need to create a user authentication system” 2. Solution Requirements: “Using JWT tokens, Express.js middleware, bcrypt for password hashing, with rate limiting” 3. Validation Criteria: “Include unit tests and handle edge cases like expired tokens and invalid credentials”

Example of Effective Prompting:

Create a React hook for managing API calls with the following requirements:

- Handle loading, success, and error states
- Support for request cancellation to prevent memory leaks
- TypeScript with proper generic typing
- Include retry logic with exponential backoff
- Return cleanup function for component unmounting
- Add JSDoc comments for documentation in docs folder

Write the output files to directory src/hooks

Advanced Prompting Techniques:

Sequential Thinking Approach Break complex tasks into logical steps and have the AI work through them methodically:

Let's build a complete user management system. Please work through this step by step:
1. First, design the database schema for users with proper relationships. Use prisma.
2. Create the backend API endpoints with Next JS
3. Implement the frontend components using ShadcnUI
4. Add comprehensive error handling
5. Write unit and integration tests in tests subdirectory
6. Create API documentation

📺 Insight: The most successful developers use what’s called “sequential thinking” - breaking down complex problems into manageable steps and having the AI work through them methodically. This approach dramatically improves code quality and reduces debugging time.

Persona-Based Prompting Frame the AI as a specific expert:

“Act as a senior TypeScript developer who prioritizes code maintainability, performance, and follows clean architecture principles. Review this code and suggest improvements.”

The “One Thing at a Time” Rule

One of the most valuable insights from experienced developers is the importance of asking for only one change at a time. As one expert explains: “I usually find that it’s best to just ask it to do one new feature or implement one new thing per prompt that I give it. Much better results.”

This prevents the AI from: - Getting overwhelmed and making mistakes - Touching unrelated code - Breaking existing functionality - Creating debugging nightmares

It is also easier to focus context around the one task at hand making it easier to produce much better results quicker.

2. Leverage Context Like a Pro

Understanding Context Windows and Limitations

AI coding agents have context windows - limits on how much information they can process as input at once. Since every response and every new input from the user adds to this context, it is important to be aware of what goes into it. Understanding and working within these constraints is crucial for maintaining coherent, project-aware assistance.

Cursor has a lot of built in tools that automatically optimize context usage and include only relevant text fragments and files into the context. However, you can still help it do its job better.

Strategies for Maximum Context Effectiveness:

File Management for Context in Cursor - Keep relevant files open in your editor - Close irrelevant files that might confuse the AI - Use specific file references with @filename syntax in Cursor - Organize your project structure logically and use locality principle to keep related functionality close in the file system.

Just like with human developers, having a coherent file structure helps AI tools as well.

Project-Wide Understanding Start sessions by asking the AI to analyze your project: “Can you analyze my project structure and give me an overview of the architecture? I’m working on a Node.js API with React frontend, using PostgreSQL and Redis.”

You can save the analyzis into a file and then reference that file in the context in subsequent requests.

The Critical Context Window Management Strategy

🎯 Expert Insight: “You want to keep all of your code files under 500 lines. You want to start fresh conversations often because longer conversations can really bog down an LLM.”

Context Layering Technique Build context progressively: 1. Start with high-level architecture overview 2. Include specific modules or components 3. Focus on a single immediate task with full context at a time

Advanced Context Management with Cursor Rules

One of the most powerful features that experienced developers leverage is Cursor Rules. These are essentially system prompts that provide persistent context across all your AI interactions.

Essential Cursor Rules Setup:

You are an expert software developer.
Write concise, efficient code.
Always comment your code.
Never erase old comments if they are still useful.

# Structure
- Sources are in src/ subdirectory
- Tests are in tests/ subdirectory
- Makefile targets should be organized and separated by / for grouping. 
- Makefile is used as shortcuts both for local convenience and for consistency between local and ci.

# Tech Stack
- Framework: Next.js
- Language: TypeScript
- UI Library: Chakra UI
- State Management: Zustand
- Database: Supabase
- Testing: Jest

# Project Structure Guidelines
- React components: src/components/
- API endpoints: src/pages/api/
- Utility functions: src/services/
- Types and schemas: src/types/

# Golden Rules
- Keep files under 1000 lines. Split long files when it makes sense architecturally.
- Write tests for all new features. 
- Use JSDoc for documentation

Cross-File Operations Strategy:

When working across multiple files, use this approach:

I'm refactoring authentication across these files:
@auth/middleware.js - Current JWT middleware
@routes/user.js - User routes that need updating  
@models/User.js - User model
@tests/auth.test.js - Tests that need updating

Please help me update the JWT middleware to handle the new user fields without maintaining backward compatibility.

3. Implement Smart Workflow Automation

Auto Run Mode

Cursor’s “Auto run mode” used to be dangerous but today (specially with claude sonnet 4 models) the number of times the model is wrong is minimal. You would save a lot of time if you enable auto run mode in cursor settings. You can still configure command allow and deny lists and enable removal protection.

The biggest piece of advice is to simply always use git and to commit often. This way you can always reset when and if cursor does something you are not happy with.

Setting Up Safe Automation:

Define Allow/Deny Lists

// Allowed commands for YOLO mode
- npm test
- npm run build
- npm run lint
- git add . && git commit -m "AI-generated changes"

// Forbidden commands
- rm -rf
- npm publish
- git push origin main
- sudo commands

Use targeted instructions to automate common repetetive tasks.

1. Tests: “Run tests and fix failures until all pass”

2. Set Boundaries: “Only modify test files and implementation, don’t change package.json”

3. Establish Success Criteria: “Stop when build passes and test coverage is above 80%”

Real-World Automation Success Stories

Comprehensive workflow covering rules setup, context management, sequential thinking, and auto mode best practices

One expert developer shares: “I really became pretty darn dependent on the agents to do things for me I would even say Okay Commit This code right write a good description and deploy it to Heroku and it would do that and it really didn’t have any problems.”

Advanced Automation Patterns:

Test-Driven Development Loop

Use these instructions:

1. Run existing tests to understand current failures
2. Implement features to make tests pass
3. Run tests after each change to get feedback
4. Refactor code while maintaining test success
5. Stop when all tests pass and code coverage target of above 80% is met

Build-Fix Iteration

Run TypeScript compiler and automatically fix type errors:
1. Execute `npm run type-check`
2. Read compiler errors
3. Fix type issues in the reported files
4. Re-run type-check
5. Repeat until clean compilation

Normally modern models understand what to do even with less verbose instructions - but the more precise you are the more exact results you will get. With AI you get what you ask for.

The Critical Safety Net: Frequent Commits

📝 Pro Tip: “Commit often commit often I cannot suggest that enough make sure that every single change you make you are committing because you can always roll back if it gets to a state that is just unfixable.”

This becomes even more critical when using automation features, as you need rollback points when things go wrong.

Workflow Integration Best Practices:

Pre-commit Automation Set up AI agents to help with pre-commit checks: - Instruct AI to configure pre-commit hooks - Automatic linting and formatting - Test execution and fixing - Documentation updates - Security vulnerability scanning

Code Review Preparation Use AI to prepare code for review: - Generate comprehensive PR descriptions - Use merge request templates to get formatting right - Identify potential issues or edge cases - Suggest additional test cases - Create documentation for complex changes

Read more

Stripe is a fantastic service and it has certainly made payment collection uneversal and easy.

However, it now has so many functions that it is easy to get confused not quite knowing how to create a robust and simple integration.

Today I'm going to cover a very straightforward implementation of the Pay as you go scheme that works very well with agentic services where the user "TopsUp" their account and then you keep track of usage on an ongoing basis and refuse service when the usage exceeds what the user has paid.

In this article we are goin to look at:

• Implementing pay as you go strategy in python

• Keeping track of user balance

• Handling stripe webhooks to ensure our view of user balance is consistent

Let's jump right into it!

Read more

Imagine this: You need to debug a complex issue. You don't know where to start. You don't want to manually have to step through the program and inspect variables yourself. You go grab a coffee and prepare for a long debugging session.

What if you could simply say, in plain English: "Figure out why this program is crashing and suggest a solution" and receive not just an answer, but a comprehensive breakdown of how to reproduce the issue?

Welcome to the future of debugging - where AI makes it possible to build a debugging assistant.

In this post we are going to implement exactly this. I'll share with you all the code and all the details of this implementation. We will connect GDB to Claude Sonnet and let it do its magic!

What You'll Discover in This Guide

I'm about to show you how to build an agent that will:

1. Start and control GDB sessions autonomously

2. Execute complex GDB commands and interpret their outputs—without you having to remember the syntax

3. Reason about program state and potential bugs like an experienced developer

4. Adapt to observed behavior in real-time and adjust its debugging approach.

Best of all? It scales to any individual use case. The LLM will adopt it’s process until it finds a solution - and you can follow along in real time and view what it is doing.

Let’s get started!

Read more

In this issue we will cover:

1. Introduction to AI Agents

2. Key Trends in AI Agents for 2025

3. Popular AI Agent Frameworks

4. Multimodal AI Agents

5. Autonomous Agent Capabilities

6. AI Agent Architectures

7. Real-World Applications

8. Future Outlook

9. References

Subscribe to This Newsletter

Stay updated with the latest developments in AI agents and other cutting-edge technologies by subscribing to our newsletter:

Subscribe to Martin Schröder Agentic AI newsletter: the only newsletter that you need to stay up to date with latest trends in AI and beyond.

Read more

• Github Repository - open-agent-api

• Schema Definition - open-agent-api

The Open Agent API is a comprehensive communication solution for connecting agents together in a standardized way. As AI capabilities continue to evolve, there's a growing need for standardized interfaces that allow developers to harness these capabilities across various applications. The Open Agent API addresses this need by providing a robust, extensible framework for building agent-based systems.

This post explores the problems the Open Agent API aims to solve, its design principles, and how developers can leverage its capabilities for building intelligent applications that can all work together. We'll examine how the API defines the protocol for the creation of individual agents, teams of agents, and the tools they can use to accomplish tasks.

Problems Addressed by Open Agent API

Before diving into the technical details, let's consider the challenges that the Open Agent API seeks to address:

1. Standardization: With multiple AI providers and agent frameworks, there's a need for standardizing how we interact with agents across the internet.

2. Composability: Building complex AI systems requires the ability to interconnect systems in standardized ways. Many types of agents need to connect together.

3. Authentication and Access Control: Since it is important to build multi-user systems that make agents available to the public, it must define standard ways of authenticating and gaining access to resources.

4. Tool Integration: Enabling agents to use tools and services that are both on the server, on the client and on other servers.

5. Team Collaboration: Allowing multiple agents to work together on complex tasks.

6. Billing and Resource Management: Since agents almost always incur costs, there must be an efficient way to handle subscriptions.

The Open Agent API provides solutions for these challenges through a well-structured and well-defined REST API specification.

Purpose of the Specification

The Open Agent API specification is designed for services that aim to provide AI agents to a wide audience. Similar to how companies like OpenAI and Anthropic offer APIs to access their language models, this specification creates a standardized interface for agent interactions.

API Overview

The Open Agent API is divided into several core components:

• Authentication: Secure user authentication via magic links, OAuth, and API keys

• Agents: Creation and management of individual AI agents

• Teams: Formation and operation of agent teams

• Chat: Low-level chat completions (compatible with OpenAI)

• Knowledge: Semantic knowledge base search

• MCP (Model Context Protocol): Tool sharing mechanism between agents

• Billing: Optional integration with payment systems

Let's explore each of these components in detail.

Authentication

The authentication system is the gateway to the Open Agent API. It supports multiple authentication methods to accommodate different use cases:

JWT Token

JWT (JSON Web Token) serves as the primary account-level authentication mechanism. When a user logs in through magic links or OAuth, they receive a JWT token that:

• Provides full access to account management features

• Allows creating, modifying, and deleting resources

• Enables subscription management and billing operations

• Has a limited lifespan and requires periodic renewal

Using the JWT token the user is then able to generate multiple API keys for different applications. JWT token acts like the main "login" token.

Magic Link Authentication

For simple email-based authentication:

POST /auth/link
{
  "email": "user@email.com",
  "base_url": "http://url"
}

This endpoint accepts an email address and sends a magic link for passwordless authentication.

This returns a JWT token as part of the AuthResponse message. This token is unverified so it can not yet be used until the user verifies their identity.

After clicking the link, users can verify their identity:

GET /auth/link/verify/{token}

At his point the token becomes usable and can be used with account API calls.

OAuth Authentication

For integrating with existing identity providers:

GET /auth/oauth/{provider}

This initiates an OAuth flow with providers like Google or GitHub. After successful authentication, the API returns a JWT token via:

GET /auth/oauth/{provider}/callback

For console applications, a device flow is also supported, allowing authentication without a web browser:

POST /auth/oauth/device/token

API Key Management

API keys are tokens that only have permissions to access agent API. They are meant to be created for each application that needs to access the agent api.

POST /auth/keys
GET /auth/keys
GET /auth/keys/{key_id}
DELETE /auth/keys/{key_id}

These endpoints allow creating, listing, and revoking API keys. Each key can have customized permissions and metadata.

Creating and Managing Agents

The Agents component is at the heart of the Open Agent API. It allows creating, configuring, and interacting with AI agents.

Creating an Agent

POST /agents

When creating an agent, developers specify:

• A name and description for the agent

• The base model (e.g., "claude-3-7-sonnet-latest")

• Instructions as (additional) instructions for the agent's behavior

• Tools that the agent can use

Example agent creation request:

{
  "name": "Research Assistant",
  "model": "claude-3-7-sonnet-latest",
  "description": "An agent that helps with research tasks",
  "instructions": "You are a research assistant that helps users find and summarize information.",
  "tools": [
    {
      "name": "web_search",
      "instructions": "Search the web for information",
      "functions": [
        {
          "name": "search",
          "description": "Search the web for information",
          "parameters": {
            "type": "object",
            "properties": {
              "query": {
                "type": "string",
                "description": "The search query"
              }
            },
            "required": ["query"]
          }
        }
      ]
    }
  ]
}

Managing Agents

List all your agents:

GET /agents

Get details for a specific agent:

GET /agents/{agentId}

Update an agent's configuration:

PUT /agents/{agentId}

Delete an agent:

DELETE /agents/{agentId}

Interacting with Agents

The API provides a powerful interface for interacting with agents:

POST /agents/{agentId}/run

This endpoint accepts a series of messages and optional tools, and returns the agent's response. For example:

{
  "messages": [
    {"role": "user", "content": "Can you research the latest developments in quantum computing?"}
  ],
  "tools": [
    {
      "name": "web_search",
      "functions": [
        {
          "name": "search",
          "description": "Search the web for information",
          "parameters": {
            "type": "object",
            "properties": {
              "query": {
                "type": "string",
                "description": "The search query"
              }
            },
            "required": ["query"]
          }
        }
      ]
    }
  ]
}

The API supports both synchronous responses and streaming via Server-Sent Events (SSE), allowing real-time updates as the agent thinks and uses tools.

Team Collaboration

This collection of interfaces gitve user the ability to create teams of agents that can collaborate on tasks.

Creating a Team

POST /teams

When creating a team, developers specify:

• A name for the team

• The member agents and their roles

• Tools available to the team manager

Example team creation:

{
  "name": "Research Team",
  "members": [
    {
      "agent_id": "agent1",
      "role": "Researcher"
    },
    {
      "agent_id": "agent2",
      "role": "Writer"
    }
  ],
  "tools": [
    {
      "name": "knowledge_base",
      "instructions": "Search the knowledge base",
      "functions": [
        {
          "name": "search",
          "description": "Search the knowledge base",
          "parameters": {
            "type": "object",
            "properties": {
              "query": {
                "type": "string",
                "description": "The search query"
              }
            },
            "required": ["query"]
          }
        }
      ]
    }
  ]
}

Managing Teams

List all your teams:

GET /teams

Get details for a specific team:

GET /teams/{teamId}

Running Team Interactions

POST /teams/{teamId}/run

This endpoint accepts messages and coordinates responses among team members. For complex tasks, the team leader agent routes subtasks to appropriate member agents based on their roles and capabilities.

Model Context Protocol (MCP)

The MCP component enables tools to be shared between agents using a standardized protocol. This allows agents to expose capabilities as tools that other agents can use. This also allows any tooling provided by the agent service to be easily integrated with desktop agents like cursor.

GET /mcp/
POST /mcp/messages
GET /mcp/sse

MCP provides a way for agents to communicate with external tools and interface with third party services.

Tools Integration

The Tools component allows registering, discovering, and using tools with agents.

Discovering Tools

GET /tools

This endpoint returns a list of available toolkits that can be used by agents.

Getting Tool Details

GET /tools/{tool_id}

Returns detailed information about a specific tool, including its parameters and usage instructions.

POST /tools

Creates a new tool definition that can be used by agents. For example, this allows the user to expose an external MCP service to their agent or team and to be able to configure it in one place without having to pass all tool parameters with every request to the agent.

Knowledge Base Integration

The Knowledge component provides semantic search capabilities for agents:

POST /knowledge/search

This allows agents to query a knowledge base for relevant information, enhancing their ability to provide accurate and contextual responses.

Subscription and Billing

For commercial implementations, the API includes subscription management:

GET /subscription/plans
POST /subscription/subscribe
GET /subscription/current
POST /subscription/cancel

These endpoints allow users to manage their subscriptions, including viewing available plans, subscribing to a plan, and canceling subscriptions.

API Key Usage Analytics

For monitoring and billing purposes, the API provides detailed usage analytics:

GET /auth/keys/{key_id}/usage

This returns information about API key usage, including request counts, token usage, and billing information.

Practical Applications

The Open Agent API enables a wide range of applications:

1. Enterprise Assistant Systems: Create specialized agents for different departments that can collaborate on complex tasks.

2. Research Tools: Build agents that can search, summarize, and analyze information from various sources.

3. Customer Service: Deploy teams of agents to handle customer inquiries, with specialists for different types of questions.

4. Development Assistants: Create agents that can write code, debug issues, and collaborate on software development.

5. Educational Platforms: Build tutoring systems with agents specialized in different subjects.

Closing thoughts

The Open Agent API provides a comprehensive framework for building agent-based systems. By standardizing the interfaces for authentication, agent creation, team collaboration, and tool integration, it enables developers to build powerful AI applications that can solve complex problems.

Let's build this interface together and define exactly what we need and how we want it to work to facilitate simple and easy collaboration between agents. Whether you're interested in implementing new features, improving documentation, or sharing your use cases, your input is valuable.

This specification is going to evolve. You have the chance to influence the future! Create a discussion on the github project page:

Open Agents API - Github

(the images are clickable. Click on them to go to additional content!)

The Dawn of a New Intelligence

Imagine waking up five years ago and describing today's AI landscape to your past self. You'd likely be met with disbelief, perhaps even laughter. Yet here we are, witnessing artificial intelligence evolve at a pace that continues to defy expectations. What began as narrow, task-specific algorithms has blossomed into something far more profound—a technological renaissance that's redefining the boundaries between human and machine capabilities.

This isn't just another technology story. It's the beginning of a new chapter in human history.

Language: The First Breakthrough

Our journey begins with language—the fundamental medium of human thought and expression. When OpenAI unveiled GPT-4, it marked a watershed moment in artificial intelligence. These systems don't just string together grammatically correct sentences; they understand context, generate creative content, and reason through complex problems in ways that feel remarkably human.

Watch: OpenAI's live demonstration of GPT-4o vision capabilities

The scale of AI-generated content is already staggering—an estimated 100 billion words per day. That's equivalent to publishing the entire works of Shakespeare approximately 1,300 times every 24 hours.

Yet quantity isn't the real story here. What's truly remarkable is the quality and versatility of this content. From crafting marketing copy to coding complex applications to writing poetry that stirs genuine emotion, these systems have transformed from tools into creative partners.

But this was just the beginning.

Vision: AI Learns to See Our World

As language models were revolutionizing text, another breakthrough was unfolding in the visual domain. DALL-E and similar image generation models demonstrated an uncanny ability to transform text descriptions into vivid, detailed images that never existed before.

Watch: How to get the best results with DALL-E 3

Consider for a moment what this means: AI can now visualize concepts it has never directly observed. It can blend styles, imagine fantastical scenes, and create visual content that would take human artists hours or days to produce—all in seconds.

The implications ripple across industries. Designers can rapidly prototype concepts. Filmmakers can visualize scenes before shooting. Architects can generate multiple renderings of spaces that don't yet exist.

But the story of AI's evolution was about to take an even more fascinating turn.

Meta-Intelligence: AI That Creates AI

If language and vision represent the fundamental input/output channels for human intelligence, what followed next ventures into territory without clear human parallels: AI systems that can create and improve other AI systems.

Watch: How AI agents are changing everything

Emergence AI demonstrated a capability that sounds like science fiction: creating its own AI agents. Meanwhile, Amazon's AGI Lab has developed advanced AI systems with decision-making capabilities inspired by robotics, allowing them to interact with the digital world much as physical robots navigate the physical one.

This represents a profound shift in the AI landscape. When artificial intelligence can improve itself—potentially at an accelerating pace—we enter uncharted territory in terms of capabilities and applications.

The implications are both exhilarating and challenging to comprehend. As philosopher Nick Bostrom noted, "Machine intelligence is the last invention that humanity will ever need to make."

Science: AI as a Research Partner

While these developments were capturing public imagination, AI was quietly transforming scientific research in ways that could prove even more consequential over time.

Watch: The Economist explores how AI is transforming scientific discovery

Berkeley's Evo 2 model represents a breakthrough in genetic research, accurately predicting the effects of genetic mutations across all domains of life. Google has highlighted AI's role in solving previously intractable scientific problems, from protein structure prediction to flood forecasting.

In each case, AI isn't simply automating rote tasks—it's enabling discoveries that would be difficult or impossible for humans working alone. The scientific method itself is being augmented and accelerated.

As one researcher put it: "We're not just using AI to do science faster. We're using it to do science differently."

Infrastructure: Building for an AI-Native World

These leaps in capability have driven corresponding advances in the infrastructure that powers AI systems. Google's Ironwood TPU is a prime example—a specialized processor designed to handle the unique computational demands of advanced AI.

These developments aren't merely technical footnotes. They represent the physical foundation that makes the AI revolution possible—and affordable. As computing power becomes more efficient and accessible, we're witnessing a democratization of AI capabilities that were once limited to tech giants with massive resources.

Collaboration: When AIs Talk to Each Other

If individual AI capabilities represent the building blocks of this new era, the next logical step is enabling these systems to work together. Google's Agent2Agent (A2A) protocol is designed precisely for this purpose—creating a standard way for AI systems to communicate and collaborate.

Watch: Y Combinator's take on the next breakthrough in AI agents

This development solves a fundamental challenge: how do we harness the specialized capabilities of different AI systems to tackle complex problems that require multiple forms of intelligence?

The A2A protocol enables a new paradigm where AI systems can seamlessly coordinate, share information, and leverage each other's unique strengths—much as human specialists collaborate on complex projects.

Education and Accessibility: AI for Everyone

As AI capabilities have expanded, they've also become more accessible to ordinary people in meaningful ways. Anthropic's Claude has found significant application in universities, helping students learn more efficiently and innovatively.

Watch: Anthropic's introduction to Claude for Education

Voice-based tools like Aqua Voice 2 are improving accessibility for people with disabilities. Custom AI agents are enabling businesses to create specialized solutions without deep technical expertise.

In each case, we're seeing AI capabilities extended to new users and use cases—creating value not just through raw technical advancement but through thoughtful application to human needs.

The Human Element: Teams Transformed

Perhaps most intriguingly, research is beginning to reveal how AI transforms human collaboration. Studies show that AI-assisted teams significantly outperform traditional teams, suggesting that AI can effectively replace or enhance certain team functions.

Watch: Atlassian's perspective on AI agents and the future of teamwork

This isn't about replacing humans with machines. Rather, it's about creating new collaborative structures that leverage the unique strengths of both human and artificial intelligence. The most successful organizations of the future will be those that master this human-AI symbiosis.

The Convergence: From Tools to Agents

As we step back and observe these developments collectively, a profound pattern emerges. What began as separate technological advances in language, vision, scientific research, and other domains is converging toward something qualitatively different—a transition from AI as tools to AI as agents.

This is the heart of our story: we are witnessing the birth of AI systems that don't just perform isolated tasks but act with increasing autonomy in complex environments. They observe, decide, act, and learn in ways that increasingly resemble agency rather than automation.

The distinction is crucial. Tools extend human capabilities but require constant direction. Agents understand goals and independently determine how to achieve them.

The Future Belongs to Those Who Understand This Shift

This evolution from AI tools to AI agents represents the central inflection point in modern technology—and perhaps in human history. As we stand at this crossroads, three truths become evident:

1. The pace of change will continue to accelerate. What seems remarkable today will be commonplace tomorrow.

2. The most valuable skills will be those that complement AI rather than compete with it. Human creativity, ethical judgment, and interpersonal connection will become even more precious.

3. The greatest opportunities will come from reimagining rather than merely automating. Organizations that simply use AI to do the same things faster will be outpaced by those who envision entirely new possibilities.

The future doesn't belong to AI. It belongs to the humans who best understand how to partner with it.

As we face this unprecedented future, we should approach it neither with blind optimism nor paralyzing fear, but with clear-eyed wonder and responsibility. We are the first generation to witness the birth of a new form of intelligence—and that carries both extraordinary privilege and profound obligation.

The tools of creation have never been more powerful. The question now is what we will create with them.

What's your perspective on these AI developments? Which capability most excites or concerns you? Share your thoughts in the comments below.

Imagine an AI agent that doesn't just respond with the first solution it finds or based on first tool it uses, but methodically works through complex problems—step by step, validating its work, and catching errors before they happen and calling more tools when needed.

Reasoning agents represent a significant advancement in AI capabilities, using simple tweaks and tool use to make models to work through complex problems methodically before producing final outputs. This tutorial explores how to build reasoning agents using the Agno framework, drawing inspiration from Anthropic's "think" tool approach.

First a friendly reminder…

Also, connect with me on LinkedIn professionally, if you maintain a LinkedIn account: https://www.linkedin.com/in/martinschroder/

What Are Reasoning Agents?

According to Agno's documentation, reasoning is the ability to think and validate before responding or taking action. Reasoning agents are AI systems designed to:

• Break down complex problems into logical steps

• Think through problems systematically before responding

• Employ tools when necessary to gather information

• Backtrack, correct, and validate reasoning steps

• Make consistent decisions across multiple attempts

As described by Ashre Puri, creator of Agno, reasoning agents implement a form of "agentic reasoning" where the agent "works through a problem step by step before presenting a response to the user." This approach combines Chain of Thought reasoning with tool use and adds the ability to backtrack, correct, and validate reasoning steps as needed.

Agno supports three approaches to reasoning:

1. Reasoning Models

2. Reasoning Tools

3. Reasoning Agents

The "Think" Tool Concept

Anthropic's research on the "think" tool provides valuable insights for implementing reasoning agents. The "think" tool creates dedicated space for structured thinking during complex tasks, allowing models to:

1. Stop and consider whether they have all necessary information

2. Process external information gathered from tools

3. Perform focused reasoning on new information

4. Navigate policy-heavy environments with detailed guidelines

5. Make sequential decisions where each step builds on previous ones

The core idea is to provide a dedicated space for the model to think through problems before taking actions or responding to users.

Ready to transform your AI assistant from a fast-but-flawed responder into a careful, methodical thinker that rivals human experts? Let's dive in.

Read more

If you're building AI agents with frameworks like LangChain or LangGraph, you're probably all too familiar with the frustration: bloated dependencies, and agonizingly slow response times and pure spaghetti code. What should be a seamless experience turns into a resource-hungry monster that is also hard to debug.

That's where Agno AI comes in.

Imagine building sophisticated AI agents that respond instantly, require minimal boilerplate code, and have all the features you need. A framework that handles everything from basic text responses to complex multi-modal teams of agents collaborating on your most challenging problems.

In this post, I'll show you how Agno AI is revolutionizing agent development with a framework that's:

• Much simpler than competing frameworks

• Extremely well organized code base that is easy to comprehend.

• Lightning fast agent creation and response times

• Multi-modal by design - handling text, images, audio and video seamlessly

• Model agnostic - no vendor lock-in, use any AI provider you want

Agno AI

Agno AI (formerly known as Phidata) is an open-source framework designed for building advanced, multi-modal AI agents. Here's what I've discovered about it:

1. Performance

   • Exceptionally fast with agent creation being much faster than competing frameworks like LangGraph

   • Highly memory efficient (50x less memory usage than LangGraph - LangGraph is soo bloated)

   • Designed for high-performance agentic systems at scale. It really does work anywhere.

2. Model Flexibility

   • Model agnostic - works with any AI model or provider without vendor lock-in

   • No dependency on specific LLM providers

3. Multi-Modal Support

   • Native support for text, image, audio, and video processing

   • Can handle various media types in both input and output

4. Tool Integration

   • Supports a wide range of tools like web search (DuckDuckGo), financial data (YFinance), etc.

   • Easy tool integration for extending agent capabilities

   • Most tools are very simple themselves - great starting point for custom development.

5. Agent Architecture

   • Build individual agents or teams of specialized agents

   • Multi-agent teams that can collaborate on complex workflows

   • Different levels of agent complexity from basic to advanced multi-agent systems

   • Incredible number of really simple samples and examples

6. Knowledge Management

   • RAG (Retrieval-Augmented Generation) capabilities via "Agentic RAG"

   • Integration with vector databases for knowledge storage

   • Support for various knowledge sources including PDFs, directories of text files etc.

7. Memory Capabilities

   • Can store and manage agent state in databases

   • Persistent memory across multiple interactions

8. Developer Experience

   • Simple API for creating agents

   • Structured output support (JSON, Pydantic models)

And more..

• Active GitHub repository with 23.9k stars and 3k forks

• Growing community with forum and Discord support

• Open-source with MPL-2.0 license

• Recently hosting an AI Agent Hackathon with prizes up to $20,000

Let's dive in!

Read more