Building Software factory for teams - prinevo.ai. Ex - engineering@ zamp.ai, @toplynehq, Goldman Sachs, Oracle
bengaluru
- Tweets 561
- Following 1,069
- Followers 415
- Likes 1,651
Pinned Tweet
Introducing Prinevo Memory - a long-term memory engine built on typed-edge capture, bi-temporal knowledge-graph supersession, and hybrid retrieval, with one engine shared across domains through a pluggable ontology layer.
Benchmark numbers, published today: LoCoMo 83.89% (mem0's own judge, n=1,986) and LongMemEval 82.60% (its own official judge, n=500) — full methodology, disclosed judges, and raw per-question results are public.
Concretely - when a fact changes, the old one is retired, not overwritten, so we can answer both "what's true now" and "what did we believe was true back then." And because relationships are typed edges, multi-hop questions - "what transitively depends on X," full blast-radius - get answered by walking the graph directly, not by hoping a bigger context window surfaces the right chunk.
Nothing enters the graph without a source, either - an unsourced claim is rejected at write time, so "why did the agent believe this" stays answerable.
The bet underneath it - retrieval is only as good as what you captured. No amount of reranking or prompt tuning fixes a system that didn't write down the right entities and relations upstream.
That's why domain understanding - an actual ontology, not just embeddings over raw text - matters so much for agent performance, and it's the problem Prinevo memory is built to solve.
These are early, measured numbers, not a finished story. We're continuing to track how this holds up as the same shared context graph + ontology layer gets used across a multi-agent system, and we'll keep publishing results as that develops.
Link in comment
ALT Prinevo Memory scores on locomo and longmemEval Benhmarks
5
2
6
1,554
sohit kumar retweeted
Stop paying for five AI agents that work in silos. Get one team of agents that share context - powered by your existing Claude and Codex subscription.
2
3
21
Having a bunch of agents in your SDLC is not enough.
Your Agentic SDLC process will only be as effective as the common context those agents are working on.
This is where the idea of a software factory becomes important.
Your product agent, coding agent, code review agent and QA agent should all operate on the same context layer. And because requirements, decisions, code changes, reviews, tests and human actions are all happening as part of the same workflow, that context can continuously get updated.
Otherwise, you just have disconnected agents with partial views of the system.
And an agent is only as effective as what it can see.
This is why I think standalone QA agents, code review agents companies will eventually have to expand across a larger part of the SDLC and become a software factory or be a part of software factory.
You can only build deep context if you are present across the workflow.
As the workflow captures more decisions and actions, agents can become more effective over time and take on more work autonomously.
This is what I am building with prinevo.ai - a software factory where agents operate across the entire SDLC with shared context, governance and a learning loop.
Today we're releasing our AI SDLC transformation playbook, where we share best practices to deploy AI at enterprise scale
Engineering leaders frequently ask how Atlassian thinks about our AI-native SDLC. This playbook is our answer, informed by our own transformation and learnings from top engineering organizations we work with
Come find us at the AI SDLC booth at Team '26 EU this week for a physical copy (and merch) atlassian.com/blog/ai-at-wor…
3
4
203
This is why banks/enterprises do a BCP( backup continuity plan) exercise once every year, where they switch over the servers etc, to ensure that in case of disaster/war they are able to run business seamlessly.
When I was in Goldman sachs I was part one of the application BCP exercise, at that time I was like why do we need to do it? But you never know what may happen.
4
191
Should we have testcases or not? U nit vs integration test?
It about how quickly can your system - human or agent, detect a failure, localize it, and fix it, without wasting unnecessary time, tokens, and compute?
And the need will be different for different systems in different domains.
In cases margin of error is less, in cases time to respond will be less.
Think from first principle, what purpose it serves, how does it help in your context, and take call accordingly.
The purpose of any test is to get feedback that something is breaking.
And if something breaks, you want to know ASAP.
Once you know it broke, you want to narrow down the exact point where it failed as quickly as possible.
So there are really two time components
- Time to figure out there is an issue.
- Time to find the root cause and fix it.
Let's say you have a pricing matrix based on customer type and order value.
Free + $500 order → 10% discount
Pro + $500 order → 15% discount
Enterprise + $500 order → 20% discount
If someone changes the Enterprise rule from 20% to 15%, a unit test catches that immediately.
You know exactly what failed and where to fix it.
Now imagine catching the same thing through an integration test.
You create an order, call the pricing API, it talks to other services, invoice gets generated, payment flow runs, and at the end you find out the final amount is wrong.
Now you have to figure out whether the issue is in the pricing matrix, API call, invoice calculation, data passed between modules, or somewhere else.
You will eventually find it, but the feedback loop is longer and the search surface is much bigger.
Now the interesting question is - does this change when agents are writing the code?
I don't think the fundamental problem changes.
For an agent also, what matters is -
- How quickly can it know something broke?
- And once it knows, how quickly can it narrow down the issue and fix it?
Yes, agents can debug and fix code much faster than humans.
And if you have time on your side, maybe you don't care. You can let the agent run for hours, execute the entire test suite, debug failures, iterate, and finally release the change.
But I still feel there is a lot of token and compute wastage in doing that if a much faster feedback loop could have caught the same issue early.
So if your integration test runs quickly, gives good logs/traces, clearly points to the failure, and the agent can reliably fix it, then maybe you don't need that unit test.
But if your integration test takes 15 minutes and just says:
"Checkout flow failed"
the agent still has to inspect multiple services, API calls, state changes, logs, etc.
You have still created a much larger search space.
So I don't think there is a black-and-white answer that you should use unit tests or integration tests.
It depends on your system -
- How fast can you run integration tests?
- How good is your observability?
- How quickly can a human or agent narrow down the failure?
- How expensive is it to write and maintain the tests?
- How quickly can the issue be fixed once found?
In my setup, integration tests are still relatively slow.
So I ask my AI to write tests for the request first and then write the code.
Unit tests give the agent an early feedback loop with a narrow failure surface.
Then integration/functional tests verify interaction points and end-to-end behavior.
As integration environments get faster, observability gets better, and agents get better at debugging, maybe we will need fewer unit tests.
So for me, it not unit tests or integration tests?
It is how quickly can your system - human or agent, detect a failure, localize it, and fix it, without wasting unnecessary time, tokens, and compute?
4
103
sohit kumar retweeted
Very few folks have heard of DDD, and even fewer understand the value it adds as systems scale.
The same is true for agentic systems. Context is essentially about understanding and modeling your domain correctly.
Agents need domain knowledge too.
1
2
158
If you are building a software factory for your team, a few must have
Orchestration - Agents take care of judgement and the work. Communication and coordination need to happen via a reliable orchestration layer.
Context Management - Manage the context of your agents. Use subagents for fresh context and well-defined subtasks, and skills when agents need to do something when certain criteria are met. etc.
Governance/Control - Ensure the agents have the right access, can pick and choose models, have cost control, can’t access secrets, and that we can audit all the actions.
Verification - Need to have a setup where agents can verify the work and create a feedback loop to complete the task.
Learning Loop - Learning from sessions/runs should not be lost. It should feed back and update the memory, modify the agent/skill, so that they perform better next time.
Everyone is suddenly talking about building their own "software factory".
Have you built one? If so, how? What does it do?
4
197
Help me visuaize the issue and the fix - helps me quickly reason about the changes done by claude/codex.
3
108
For my day to day work - I want speed, right now lot of time I wait for models to complete the task.
30 percent faster and cheaper and comparable performance to opus.
Will have to try this out.
Introducing Claude Sonnet 5.5, the second model in the Claude 5.5 family.
It’s a clear upgrade over Sonnet 5, runs more than 30% faster, and costs up to 30% less for most work.
3
175
With AI generating 1000s of test cases, having intelligent CI layer that can figure out the blast radius of a change and run only the test cases that are actually required.
This will heavily depend on context layer which captures your system and product understanding really well.
I am building software factory which will have all the context needed for agents to do the job in most effective way.
And even after that, we need CI infrastructure that can execute those tests much faster than it does today.
CI has become the top bottleneck of every engineering team I talk to (including Lindy). Our CI spend has become stratospheric.
4
176
The purpose of any test is to get feedback that something is breaking.
And if something breaks, you want to know ASAP.
Once you know it broke, you want to narrow down the exact point where it failed as quickly as possible.
So there are really two time components
- Time to figure out there is an issue.
- Time to find the root cause and fix it.
Let's say you have a pricing matrix based on customer type and order value.
Free + $500 order → 10% discount
Pro + $500 order → 15% discount
Enterprise + $500 order → 20% discount
If someone changes the Enterprise rule from 20% to 15%, a unit test catches that immediately.
You know exactly what failed and where to fix it.
Now imagine catching the same thing through an integration test.
You create an order, call the pricing API, it talks to other services, invoice gets generated, payment flow runs, and at the end you find out the final amount is wrong.
Now you have to figure out whether the issue is in the pricing matrix, API call, invoice calculation, data passed between modules, or somewhere else.
You will eventually find it, but the feedback loop is longer and the search surface is much bigger.
Now the interesting question is - does this change when agents are writing the code?
I don't think the fundamental problem changes.
For an agent also, what matters is -
- How quickly can it know something broke?
- And once it knows, how quickly can it narrow down the issue and fix it?
Yes, agents can debug and fix code much faster than humans.
And if you have time on your side, maybe you don't care. You can let the agent run for hours, execute the entire test suite, debug failures, iterate, and finally release the change.
But I still feel there is a lot of token and compute wastage in doing that if a much faster feedback loop could have caught the same issue early.
So if your integration test runs quickly, gives good logs/traces, clearly points to the failure, and the agent can reliably fix it, then maybe you don't need that unit test.
But if your integration test takes 15 minutes and just says:
"Checkout flow failed"
the agent still has to inspect multiple services, API calls, state changes, logs, etc.
You have still created a much larger search space.
So I don't think there is a black-and-white answer that you should use unit tests or integration tests.
It depends on your system -
- How fast can you run integration tests?
- How good is your observability?
- How quickly can a human or agent narrow down the failure?
- How expensive is it to write and maintain the tests?
- How quickly can the issue be fixed once found?
In my setup, integration tests are still relatively slow.
So I ask my AI to write tests for the request first and then write the code.
Unit tests give the agent an early feedback loop with a narrow failure surface.
Then integration/functional tests verify interaction points and end-to-end behavior.
As integration environments get faster, observability gets better, and agents get better at debugging, maybe we will need fewer unit tests.
So for me, it not unit tests or integration tests?
It is how quickly can your system - human or agent, detect a failure, localize it, and fix it, without wasting unnecessary time, tokens, and compute?
3
5
335
No one is a backend engineer anymore.
Almost every hiring request I am getting on LinkedIn now has AI Engineer as the role.
6
181
