In [12], James Dalziel discusses four primary user types or roles into a CAA system: student, designer/author, instructor, grader. Agar explicitly alters only a single one of these, the grader role. The student and instructor roles are handled here at UCR CS&E by the Turnin system, which provides a web-interface for instructors or TAs to create electronic drop-boxes for assignments. The students use a similar web-interface to select a course and assignment to submit into, are notified whether their submission was on-time or late after submitting, and are given a cryptographically signed receipt for their files. Agar has been developed to work primarily with the directory of student submissions that Turnin generates, but the two systems are not yet tightly coupled in any way.
In general, the use of Agar can be completely hidden from the students. An intriguing and so-far unused possibility exists to generate a rubric under Agar bundled with sample input and output files and distribute this to the students. By doing so, the student can run the same automated tests on their own code before submitting, thus reducing any chance of misunderstanding in the problem statement and shifting some of the burden from the grader back to the student.
Agar may slightly affect the role of the designer or author of an assignment, by altering the types of things that are assigned to be easier to grade within the Agar framework. Programs that have well-specified input and output formats are very well supported by Agar, as are programs that can be graded by running regular expressions against the source, but complicated programs that have a great deal of imprecision or creativity leverage less from Agar. This is really a secondary effect on behavior, rather than a required behavioral change, but is worth mentioning.