Agentic Engineering & SR&ED: What Changes for Your Claim
If your team is moving from traditional agile development to agentic engineering, where engineers direct AI agents that write, test and deploy code, your SR&ED claim will change. There is eligible R&D that qualifies for SR&ED, but who does the work, what costs are claimable and how it’s documented are different.
What is agentic engineering?
IBM describes agentic engineering as the professional practice of using engineering expertise to orchestrate, guide and govern semi-autonomous AI agents across the software development lifecycle.
Agentic engineering is not vibe coding. In vibe coding, users (technical or not) prompt their way to an application. Each iteration is driven by functionality. Typically vibe coding produces proof-of-concepts built on code that is not production quality.
Agentic engineering is practised by experienced software engineers and relies on strict specifications, automated testing, quality assurance and security reviews, just as any good engineering team would. This distinction is important for SR&ED, which requires technological advancement through systematic experimentation, not simply building a cool, innovative product.
Can I still claim SR&ED after transitioning to agentic engineering?
Yes. The eligible work is concentrated in your senior engineers, the humans in the loop.
Traditionally, senior team members led the experimental design and analysis while intermediate and junior developers implemented the code. Now agents do much of the implementation, and do it much more quickly. Your senior engineers still identify the technological uncertainty, form hypotheses, design experiments, evaluate results and refine requirements. With faster iteration, that cycle simply runs more often. Agents also run deployment and testing, but people still define what success looks like and analyze and interpret the results and come to conclusions.
As with traditional software engineering, not all work is claimable. Simply getting an agent to produce a standard feature is routine development. There must be a technological uncertainty to overcome in order to be SR&ED eligible. Be it defining a new model because available models don’t fit the technical requirements, or overcoming a performance barrier because standard algorithms are limited, the SR&ED work is related to overcoming the uncertainty, regardless of whether the development method is traditional or agentic.
What about my SR&ED expenditures?
Salaries. A smaller team of intermediate and junior developers means a smaller SR&ED salary base.
Tokens and cloud compute. These may qualify as overhead and other expenditures, but only under the traditional method, and each cost must be directly related to the SR&ED and incremental. Usage-based spend tied to specific projects is a stronger candidate than a flat subscription, so tag usage by project from day one.
Your overhead method election. The proxy method is based on 55% of your salary base, so it shrinks as headcount does. If token and compute costs become significant, it's worth modelling both methods before filing.
Capital and lease expenditures. Capital expenditures returned to the program for property acquired on or after December 16, 2024, with lease costs eligible from the same date. The property must be used almost exclusively for SR&ED. The rules are complicated, so it’s worth getting help with this. We recently helped a client that invested in specialized GPU hardware to support its R&D, claim that infrastructure spend as an SR&ED capital expenditure.
SR&ED documentation on an agentic team
The requirement hasn't changed. You must demonstrate technological uncertainty, and you need contemporaneous documentation of the experiments: hypotheses, development, testing, analysis and conclusions.
Documentation has always been a struggle for engineering teams. At agentic speed, writing it up by hand won't keep up. The good news is that an agentic workflow already produces much of the raw evidence (specifications, commits, test runs, results). Add a documentation agent that assembles it into a usable record.
What makes a good SR&ED documentation agent?
Technological uncertainty: what is standard practice, and where does it fall short?
Hypothesis: captured before the experiment runs, not reconstructed afterwards.
Experiment: what was built, with links to the commits and specifications.
Results: test outcomes, including the failures.
Analysis and conclusions: what was learned and what the next iteration is.
People and cost: which engineers directed the work, plus token usage tagged by project.
Human review: an engineer signs off on each record, because the claim is your responsibility, not the agent's.
If you've transitioned to agentic engineering, or are thinking about it and want to ensure you are still covered for SR&ED, get in touch.
